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0 System for matching of buyers and sellers with risk minimization. 

0 A risk control matching system for trading instmment, such as foreign exchange currencies, is provided in 
which bids are automatical! matched against offer for given trading instruments for automatically providing 
matching transactoins in order to complete trades for tiie given trading instruments, and broken trades are 
readily identified with a minimization of risk to tiie parties to a potential matching transaction. The system 
comprises a host computer (20) for maintaining a book database (118) comprising all of tiie active bids and 
offers In tiie system by trading instalment, a f ansaction originating keystation (24a) for providing a bid on a 
given trading insrument, a counterparty keystation (24b) for providing an offer on the given trading instrument a 
network (22) for interconnecting ttie host (20) and ttie kestation (24, 25b), and a plurality of transacton deks (70a, 
70b. 70c), connected to the host (20) for detecting the occurrence of the potential matching transaction and 
"voting" on whetiier to commit to tiie match. Positive match acknowledgment signals are provided to tiie host 
(20) by ttie keystations (24) involved in the trade in response to receipt of match notification signals form the 
host (20). IKf one of \hese signals is not received back, tfie host (20) detects a broken trade to have occured. 
Each of the keystations (24) provides an application based heartbeat signal to tiie host (20) which enables rapid 
detection of keystation (24) failure. In ttie event of detection of such keystation (24) failure, the host (20) cancels 
all bids and offers associated with tiie failed keystation (24). 
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RISK CONTROL MATCHING SYSTEM 



The present invention relates to matching systems for effectuating trades of trading instruments through 
automatic matching in which buyers and seliers who are willing to trade with one another based on 
spedfied criteria, such as price, quantity and credit, may automatically trade when matching events occur 
satisfying these criteria, and more particularly to such matching systems in which risks are minimized as to 

5 losses due to broken trades. 

Information retrieval systems for financial information, such as stock mar1<et type of information and 
money market information, nonmaliy employ a transfer of data in a high-performance, real-time infomiation 
retrieval network in which update rates, retrieval rates and subscriber and/or user population are generally 
very high. An example of such a system is REUTERS DEAUNG SERVICE which is used in the foreign 

10 exchange or money market. Such systems, while providing rapid video conversation capability, are not 
anonymous systems nor do they provide for automated anonymous trading such as is possible in a 
matching system. Of course, conversational dealing systems have their place in the market and serve 
particular needs where appropriate. However, anonymous matching systems are also often desired and, by 
their very nature, do not normally employ a conversation capability since the parties to the transactions are 

75 unknown until the transaction has been completed. Examples of satisfactory prior art video conversational 
systems for use in connection with trading of financial information are disclosed in commonly owned US-A- 
4.531.184:4,525.779 and 4,404,551, by way of example. Prior art examples of matching systems used in 
connection with the trading of trading instruments are disclosed in US-A- 4.412,287. which discloses as an 
automated stock exchange in which a computer matches buy and sell orders for a variety of stocks; US-A- 

20 3.573.747. which discloses an anonymous trading system for selling fungible properties between subscrib- 
ers to the system; US-A- 3,581.072, which discloses the use of a special purpose digital computer for 
matching orders and establishing market prices in an auction market for fungible goods; and US-A- 
4,674.044, which discloses an automated securities trading system. However, none of these prior art 
matching systems implements or suggests the use of risk controls to minimize risks as to losses due to 

25 broken trades, which are situations in which you are not entirely sure which trades have been completed or 
not due to network failure, or control sytem or host failure, keystation failure, ail of which could result in one 
party thinking a trade or match had occun-ed while the counterparty was completely unaware of the trades. 
Moreover, no prior art distributed anonymous matching sytems are known to applicant in which broken 
trade clients are provided when there is a system failure which presents all parties to the trade from being 

30 notified of the transaction. Furthermore, no such prior art matching systems are known to application in 
which positive match acknowledgements are utilized in attempting to avoid broken trades. In addition, no 
prior art distributed matching systems are known to applicants in which directed messages are employed 
between the keystations in the system and the central system to update the local entry order data bases 
and broadcast messages are employed to update the keystation book which is a restricted subset of the 

35 host or central system book. Furthermore, none of these prior art system employ summary books at the 
local keystations as subsets of the host or central system book. 

Although dynamic control of the content of a local receiver data base from a transmitted data base in an 
information retrieval communication network has been previously employed by applicants' assignee, such 
as disclosed in US-A- 4.745.559 and 4,750.135, these systems are, nevertheless, different from the type of 

40 risk control employed in the system of the present invention in which a plurality of isolated computers 
"vote" on completion of trades based on the detection of application generated "heartbeats" from the 
parties to the potential matched trade, and in which broken trade alerts are provided when there are 
systems failures during a trade which prevents all parties to tiie trade from being notified of tiie transaction. 
Thus, the sytem of the present invention for providing a distributed matching system in which risks are 

45 minimized as to losses due to broken trades overcomes the disadvantages of the prior art. 

According to the present invention., there is provided a risk control matching system for trading 
instruments, such as foreign exchange cun-encies, is provided in which bids are automatically matched 
against offers for given trading instruments for automatically providing matching transactions in order to 
complete trades for the given trading instruments, and broken trades are readily identified with a 

50 minimization of risk to tiie parties to a potential matching transaction. The system comprises a host 
computer for maintaining a host book database comprising all the active bids and offers in tfie system by 
trading instalment, a transaction originating keystation for providing a bid on a given trading instrument to 
tiie system for providing ttie potential matching transaction, a counterparty keystation for providing an offer 
on the given tradir^g instrument involved in the potential matching transaction, a networic for interconnecting 
ttie host computer, tiie transaction originating keystation and tiie counterparty keystation in tiie system for 
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enabling data communications therebetween, and a plurality, such as two or three, of matching transaction 
detecting means connected to the host computer for detecting the occurrence of the potential matching 
transaction by the host computer. Each of the transaction detecting means has an associated database for 
storing data with respect to the potential matching transaction. The host computer further comprises means 

5 for processing the potential matching ti^sactions for a given trading instrument for providing a transaction 
detecting means. The transaction detecting means, such as a plurality of isolated computers, at least one of 
which Is at a site remote from the o there and at least two of which are relatively close to each otiier, each 
comprise means responsive to the match indication signal for detecting the occurrence of the potential 
matching transaction at the host computer, and further comprise means for providing an acknowledgment 

70 signal back to the host computer in response to receipt of a predetermined plurality of these acknowledg- 
ment signals, or "votes', such as two of three, for updating the host back database based on tiie matching 
transaction and for providing a directed message tot he transaction originating keystation and the 
counterparty keystations acknowledging the occumence of the matching transaction. Thus, the requirement 
for the various exchange of signals minimize risks as to losses due to broken trades. 

75 In order to minimize such risks due to keystation failure, positive match acknowledgment signals are 
provided to the host computer by the respective keystations involved in the trade in response to receipt of 
match notification signals from the host computer. If one of the match acknowledgment signals is not 
received back, the host detects a broken trade to have occurred. Moreover, each of the keystations in the 
system provides an application based heartbeat signal, such as message data or a no data heartbeat 

20 message, to the host computer. In a predetermined detection interval, which enables copied detection of 
keystation failure. In the event of detection of such keystation failure, the host computer cancels all bids and 
offers associated witii tiie failed keystation. The heartbeat detection intewal is preferably set at a value high 
enough to mask transients but still low enough to minimize system vulnerability to broken trades, such as 
an eight second detection time. Thus, there are in reality at least three parties to every trade which must be 

25 "present" moreover to minimize the risks as to broken trader; namely, a buyer keystation, a seller 
keystation, and tiie central system and they should all have tiie scenic view of the trade, or at the very 
least, a permanent record of tiie trade should be maintained and notification of the trade should be 
communicated to all of the parties to tiie trade. 

An example of ttie invention will now be described with reference to tiie accompanying drawings in 

30 which: 

FIG. 1 is an overall system functional block diagram of tiie distributed risk control matching system of 
tiie present invention; 

FIG. 2 is a functional block diagram of the system of FIG. 1 illust^ng tiie flow of infonmation in 
connection witfi the entry of a bid and tiie entry of an offer in the distributed risk control matching 
35 system of FIG. 1; 

FIG. 3 is a functional block diagram similar to FIG. 2 of the flow of information in tiie distributed risk 
control matching system of the present invention in connection with a hit bid or trade; 
FIG. 4 is an illustrative diagram of a logical model of a book mari<et. pre-posting, at the host or central 
system of the present invention and illustrates the central system book in accordance witii the present 
40 invention; 

FIG. 5 is an illustrative diagram similar to FIG. 4 illustrating a typical keystation book as a subset of the 
central system book illustrated in FIG. 4; 

FIG. 6 is a functional block diagram illustrating the flow of infonmation in the system of the present 
invention in connection with a typical matching transaction, witii the risk confrol transaction desks being 
45 omitted; 

FIGS. 7 - 12 are illustrative diagrams of a typical IXM update broadcast message structure in accordance 
with the system of the present invention: 

FIG. 13 is an illustrative diagram similar to FIG. 4. illustrating a book market entry position, at market, 
based on the example of RG. 4; 
so FIG. 14 is an illustrative diagram similar to Fid. 4 of book martlet entry position, with the a-eation of a 
new sub-book based on tiie book illustration of FIG. 4; 

FIG. 15 Is an illustration similar to FIG. 4 of an auction market entry position, market equal, based on tfie 
book of FIG 4; 

FIG. 16 is an illustrative diagram similar to RG. 15 of the auction maritet entry position, with the market 
55 bettered, based on tfie book of FIG. 4; 

FIG. 17 is an Illustration of a logical model of tiie book market, similar to RG. 4. after posting; 

FIG. 18 is an illustrative diagram similar to FIG. 4 of tiie logical model of the book market of FIG. 4 after 

trade;. 
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RG. 19 is an illustrative diagram showing typical order types which may be implemented with the 
system of the present invention; 

FIG. 20 is an illustrative diagram of a typical credit limit display of assigned trading party credit limits at 
given client site In accordance with the system of the present invention; 
5 FIG. 21 Is an illustrative diagram of a typical potential broken trade situation in accordance with the risk 
control distributed matching system of the present invention; 

FIG. 22 is an illustrative diagram of the flow of messages and control between keystations host, and 
transaction desks in order to Implement the risk control features of the present invention; 
RG. 23 Is an illustrative diagram of the heartbeat detection function of the present invention illustrating a 
10 reconfiguring of the network around a failure in accordance with tiie present invention; 

FIG. 24 is an illustrative diagram of the fields contained in a typical match record in accordance with tiie 
present invention; 

FIG. 25 is an illustrative diagram of the values of match status computed for a given buyer notification 
status and seller notification status In accordance witii tiie present invention; 
75 RG. 26 is an illustrative diagram of the steps in trading both transaction desk type trade arbitration, in 
accordance with the p resent invention; 

FIG. 27 is an illustrative diagram of a typical data flow of transactions in accordance witii the present 
invention; 

FIG. 28-31 are illustrative diagrams of the state of ttie book witii respect to various typical transactions in 
20 accordance with the present invention; 

FIG. 32 is an illustrative diagram of typical match notification transaction in accordance with the present 
invention; and 

FIG. 33 is an illustrative diagram of match acknowledgment transactions in accordance with tiie present 
invention. 

25 

Best Mode for Carrying Out the Ir^ventiof} 



30 Refening now to to drawings in detail and initially to FIG. 1 ttiereof. tiie system of the present invention 
is a distributed anonymous matching system for use in trading various trading instniments. such as different 
foreign exchange cun-encies, which employs risk control to minimize tiie risk associated with broken trades, 
which are trades which occur whenever you have a network failure or a system failure or a keystation 
failure, and you are not entirely sure what fades were or were not completed at that time. In the system of 

35 the present invention as described herein, ttie trading is effectuated through anonymous matching as 
opposed to through tiie conversation video system described in US-A-4.531. 184; 4.525,779; and 4,404,551, 
commonly owned by applicants* assignee herein. Thus, tiie distributed risk control matching system of the 
present invention may be tiiought of as a computerized exchange in which its central role is to identify a 
buyer and a seller who are willing to trade with one anotiier based on specified criteria, such as price, 

40 quantity and credit, witfi, as will be described in greater detail hereinafter, real time prices preferably being 
subject to real time credit Thus, preferably, credit controls are used to determine the quantity of 
permissible match at ttie lowest common credit limit and the best bid/ask price for tiie largest available 
quantity to automatically complete a matched trade in tiie anonymous trading system of the present 
Invention. When such a matching event occurs, preferably the buyer and seller are informed of the trade 

45 and sufficient infonnation is tiien provided to tiiem to complete the physical clearing of the transaction. In 
order to support this central function, the matching system requires various support functions one of which 
is preferably tfie maintenance of summary maricet infonnation on tiie participant's workstation or keystation 
displays at tfie various client sites. Preferably in the system of the present invention, at all times tiie system 
vflll display tiie best inside price for every instrument traded on tiie system. The best inside price is 

50 preferably defined to be tiie highest value bid and ttie lowest value offer in tiie system. Preferably the 
prices are displayed together witti tiie quantity bid or offered at tfie specified price so tiiat the trader at the 
keystation can observe the market activity. 

By observing tiie mart<et activity, tiie tinder can decide whetiier to enter a bid. or enter an offer into tiie 
maricet in an effort to complete a matching transaction. Preferably, the anonymous matching system of tiie 

55 present Invention essentially maintains a book of bids and offers in the central system 20 or host computer. 
A user or keystation at a client site, such as client site 26a or 26b Illustrated in FIG. 1. by way of example, 
interacts with the book by submitting bid, offer, hit, or take transactions. The order entry function is 
preferably conventionally achieved ttirough data entry using a conventional keyboard, pointing device such 
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as a mouse or any other conventional data entry tool. The central system 20 preferably validates the 
transaction request, processes the bid. offer, hit or take according to the rules of the market, and attempts 
to find matches between this new entry and tiie other bids and offers posted in the system book, subject to 
grc»ss counterparty credit limits, as will be described in greater detail hereinafter, between the potential 

5 counterparties to a potential matching transaction. If a match is found, and satisfies all criteria, including not 
exceeding tiie gross counterparty credit limit then the trade is preferably automatically executed, the 
participants to the trade are informed subject to the risk control to be described in greater detail hereafter 
with reference to RGS. 21-23. Ail databases and trader screens are updated as to tiie quantities traded and 
the quantities remaining and. if desired, a clearing agency may be informed as to the details of the trade so 

TO that payments and exchanges may be completed. If. on tiie other hand, a match cannot be found, or the 
gross counterparty credit limit is exceeded by the potential match which would otiienfvise match t»ased on 
price and quantity per se , then the system preferably either disposes of the entry for hit or take or keeps 
the entry for bid oT offer for later processing. Preferably in ail cases transactions are processed to 
completion according to certain rules to be described in greater detail hereinafter and the various client 

75 sites 26a, 26b preferably receive real-time updates of the new status of the trading instruments. Thus, as 
shown and preferred In FIG. 1 , the client site systems 26a and 26b only two of which are shown by way of 
example in FIG. 1 . submit transactions, such as represented by reference numeral 30, as well as assigned 
trading party credit limits, to the central system 20 via tiie communication network 22. As will be explained 
in greater detail hereinafter with reference to FIG. 6. the submission of a transaction 30 from a client site 

20 26a or 26b to the central system 20 will preferably result in one or more messages, represented by 
reference numeral 32, going directiy back as a directed message to the client site 26a in this example, 
which initiated the transaction message. Another effect of the transaction message 30 being sent to the 
central system 20 is that for certain sorts of transactions, a broadcast message 34 is generated by the 
central system 20 which is then delivered to all client sites 26a, 26b attached to the central system 20. 

25 Thus, tiie directed response or tiie directed message 32 only goes back to the particular client site 26a and, 
more particularly, tiie particular keystation, 24a by way of example, at tiiat client site 26a which initiated the 
transaction message whereas the broadcast message 34 goes to ail client sites 26a. 26b and all of the 
various keystations associated at those client sites 26a, 26b. With respect to the assigned trading party 
credit limits, it is these limits which are used by the central system 20 to determine the anonymous gross 

30 counterparty credit limits which are used to control the completion of matching transactions. By way of 
example, in RG. 1 a typical client site 26a is shown as having keystations 24a, 24b, 24c through to 24n with 
the number of keystations merely being limited by the capacity of the system and the desired processing 
time. With respect to tiie distribution of tiie functionality in tiie system of the present invention, tiie 
communication network 22 preferably does not really play a part in that it is transparent to transactional 

35 information. By this what is meant is tiiat when tiie transactional information leaves tiie client site 26a, for 
example, it could t>e, if desired, encrypted or garbled in a way that the only other entity which could 
understand it would be the cental system 20 and that would be in'elevant to the function of tiie network 22 
since the network does not took at the messages, does not process the messages, and merely transfers 
these messages to tiie appropriate parts of tiie system, such as to the central system 20. In this regard, the 

40 network 22 is functioning similar to a paired cable in that it is a conduit to pass tiie infonrtation back and 
forth. Of course, tiie network 22 has various other communication functions which, however, for purposes of 
understanding the present invention are unnecessary to go into. Suffice it to say tiiat preferably, tiie 
communication network 22 uses a protocol which can be termed hierarchal fan-out in which one node 
transmits to multiple nodes which in tum transmits to multiple other nodes. Thus, network 22 helps 

45 implement broadcast capabilities integrated witii a message switching network to achieve full tolerance and 
broadcast distribution. It should be noted, when a potential match occurs, and the gross counterparty credit 
limit is not exceeded for that potential rriatch. the central system 20 will preferably send directed messages 
or responses to all of those parties in tiie system that were involved in the match, so that in some 
instances, two. three or more client site 26 may be involved in receiving tiie directed message. However, 

50 this still differs from the broadcast message which is sent to all client sites irrespective of their involvement 
in a particular match. 

Referring now to FIG. 2, this figure illustrates a typical data flow in accordance with the system of the 
present invention for entry of a bid or entry of an offer, with the network 22 being omitted since, as was 
previously mentioned, it is transparent to transactional Information. Rrst discussing the enter bid event in 
55 accordance witti the system of the present invention, keystation 1 or 24a, submits a bid transaction to the 
central system 20. The directed message or directed response 32 which It receives back from the central 
system or host 20 is tenmed a bid acknowledgment or BID-ACK. This acknowledgment Is a command 
acknowledgment which is preferably followed by an entry position message and. as was previously 
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mentioned, is directed directly back to the keystation 24a. In addition, as shown and prefenred in RG. 2. a 
bid update message is broadcast by the central station 20 to all keystations in the system, such as 
represented by reference numeral 34a in RG. 2. This broadcast message 34a preferably occurs if this new 
bid 32a was the new best bid in the system, or was an additional quantity being bid at the best price in the 

5 system. Thus, If this new bid 32a is at the highest price or better or higher, then it will result in a bid update 
broadcast message 34a going out throughout the system. In addition, as also shown by way of example In 
FIG. 2. if it is desired to disseminate an external ticker 60. then the ticker information 60 will also be 
provided of the best bid or best offer. Preferably, tiie same procedure is followed with respect to entry of an 
offer with the messages, in tiiis instance, being identified as offer, given reference numeral 51, offer 

70 acknowledgment or OFFER-ACK. given reference numeral 32b, and the broadcast message for offer 
update, being given reference numeral 34b. 

Refen-ing now to FIG. 3. the data flow in accordance witii the present invention is illustrated with respect 
to a situation in which there Is a hit bid resulting in a trade. In this situation, there is substantially more 
activity than in the situation previously described witii reference to FIG. 2. Thus, as shown and prefen-ed in 

15 FIG. 3, if keystation 24b submits a transaction called "hit bid", represented by reference numeral 62. to the 
central station or host 20. a hit acknowledgment or HIT-ACK. represented by reference numeral 64. is 
provided back to keystation 24b as a directed message. At tiiat point, tiie central system 20 will recognize 
tiiat a match is possible because the "hit bid" message says that keystation 24b is willing to trade at the 
bid price. Assuming that the gross counterparty credit limit Is not exceeded for this potential matching 

20 transaction, the central system 20 will determine tiiat a match is possible. Preferably, however, as will be 
described in greater detail hereinafter with reference to RGS. 21-33. before committing to the match, the 
central system 20 gets involved in a risk limiting protocol using a plurality of transaction desks, witii one 
such transaction desk 70 being illustrated in FIG. 3. which determines whether the trade is possible, and if 
so, acknowledges tiiis to tiie central system 20. Assuming that a trade is possible, and the gross 

25 counterparty credit limit has not been exceeded, tiien a match occurs. At tiiat point several messages are 
generated from the central system 20. One of these messages is termed the match message, given 
reference numeral 65, which is a directed message that goes to tiie bidder, which in this instance is 
keystation 24b, and to the keystation 24a which originally owned tiie bid. Thus, in this instance, directed 
messages go to more than one keystation 24. Preferably, every match must be acknowledged so there Is a 

30 match acknowledgment message. MATCH-ACK which comes back from the buyer and seller keystations 
24b and 24a and is used to detenmine tiiat tiie match was in fact received correctiy and that tiie deal can 
be considered complete at that point In addition, a broadcast message is generated that a trade has 
occun-ed which trade update message, given reference numeral 67. may possibly cause a new best bid to 
occur or could affect tfie quantity or price at tiie top of tiie book. Again, if tiie trades and best bids go into 

35 the ticker 60. ttien this infomnation is provided to tiie ticker as well. Similarly, if clearing Information is 
provided to a clearing house, tiiis too occurs as represented by reference numeral 69. In addition, as shown 
and preferred, trade tickets may also be generated. Thus, trade ticket infomnation is also preferably 
provided to tiie participating keystations 24a and 24b so that tiie tirade tickets can be generated. 

Refemng now to FIGs. 4 and 5. illustrations of typical books employed in the distributed risk control 

40 matching system of tiie present invention are shown, witii FIG. 4 Illustrating a typical book at tiie central 
system 20 and FIG. 5 illustrating a typical keystation book at a typical keystation such as keystation 24a. 
based on the book of RG. 4. The central station or host book illustrated in RG. 4 is a logical model of ttie 
book maricet pre-posting and is divided into a bid side and an offer side. Each box in the diagram preferably 
stands for an entry into the side of tiie maricet. The value in the upper left hand corner of tiie box represents 

45 tiie price of tiie trading instrument and tiie value in tiie lower right hand comer represents tiie primary 
quantity of tfie trading instrument As furtfier shown and preferred in FIGS. 4 and 5. on ttie bid side ttie 
highest absolute value is at ttie top of the book and tiie lowest absolute value is at ttie bottom of the book, 
whereas on the offer side the worst relative offer value is at tiie top of tiie book and tiie best relative offer 
value is at the bottom of the book. In addition tiie time order of bids and offers goes from left to right with. 

so on tiie bid side, tiie last bid being left most and tiie first bid being right most whereas on the offer side, tfie 
first offer is left most and tiie last offer is right most This convention is also followed in connection with ttie 
keystation book of FIG. 5 which is a subset of the system or central station or host txx3k of FIG. 4. Thus, as 
can be seen in FIG. 5, ttie keystation books located at the client sites 26 maintain copies of the best bids 
and offers contained in the host book of RG. 4 and use ttiat information to generate displays at ttie 

55 keystations 24. In addition, as was previously mentioned, tfie display deptii of tfie keystation book is 
controlled by tiie host computer 20. For example, in FIG. 5. a display depth of 3 is illustrated on tiie bid 
side and ttie offer side, ft is ttils display deptti which helps restrict tiie subset of the total deptii of ttie book 
contained at tiie host computer or central system 20. In reality, there are two controls on the display deptii, 
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one is a central control by the host computer 20 which determines the maximum possible display depth for 
the keystation book, and the keystation 24 itself which, within that maximum parameter, can further limit the 
display depth of the book. Of course, the host computer also restricts the subset of the host book by 
limiting other information such as by withholding the identities of the parties until the transaction is 

5 completed and such other things as net together prices, and net together quantities, and maintains gross 
counterparty credit limits anonymously, not distributing assigned tiding party credit limits to tiie keysta- 
tions. It should be noted tiiat in the illustrative example of RGS. 4 and 5. bids and offers of equal goodness 
are drawn on tiie same order down the line. The central system book maintained by ttie host contains 
detailed infomnation from each client site on tiie particulars of each bid or offer. Preferably each bid and 

10 offer is identified witti a token to give it a unique handle by which it can be referred to in future fransactions 
and is time-stamped based on entry into the system. As furtiier shown and preferred in RG. 5, tiie 
keystation book is a summary book which contains accumulated summaries of bids at tiie same price and 
offers at tfie same price. Thus, by way of example, block 71 in RG. 4 is a summary of blocks 73. 75 and 77 
In FIG. 4. which shows a total quantity of 10 at tiie price of 138.86. and block 80 is a summary of blocks 82 

75 and 84 in RG. 4 which shows a total quantity of 14 at tiie price 138.38. Similarly, on the offer side, block 86 
is a summary of blocks 88 and 90 in FIG. 4. showing a total quantity of 9 at an offer price of 139.9. and 
block 92 is a summary of blocks of 94. 96 and 98, showing a total quantity of 13 at an offer price of 139.70. 
It should be noted tiiat witii respect to the offer side of FIG. 5, since tfie display depth is only three, tiie 
fourth worst offer represented by block 100 in RG. 4 does not appear in the keystation book of RG. 5 since 

20 it is outside the designated display deptii range. 

Wrtii respect to the user entry record maintained at the central database 20, preferably such items as 
the bidder offer indicator, the instrument ID number, tiie quote, the quantity, tiie time-stamp, tiie keystation 
transaction number, the host transaction number, the assigned trading party credit limits, etc. are main- 
tained. If desired, different trading instruments may be quoted in different ways. For example, you may 

26 have some trading instruments quoted on the fc>asls of absolute price and others on the basis of yield or 
discount, and so on. In addition, clearing information may be stored at the central system 20. As was 
previously mentioned, this type of information fully qualifies the entry to the host computer or central 
system 20 which can perform matching based on gross counterparty credit limits and tiie collection of bids 
and offers tiiat it has at any particular point in time, whereas the client site or keystation 24 preferably 

30 maintains copies of only some of these fields so that it can create displays. Thus, the host or central 
system 20 reduces the amount of networi< overhead that is required by transmitting only summary 
information about the book and typically restricts the price depths that are sent down, such as the deptii of 
three given in the example of FIG. 5. in addition, as previously mentioned above, the host will aggregate 
quantities at the same price level as illustrated in FIG. 5. In allocating tiie accumulated summary to a match. 

35 the rules generally followed are tiiat it goes by price, time of entry to tiie system, and by credit. 

Now we shall briefly discuss tiie IXM update message structure for broadcast messages. IXM as used 
herein is another name for tiie book or an instrument crossed witfi a market. The book maintenance 
protocol or operation block protocol is preferably a way for instructing the client sites 26 to add, drop or 
remove particular sub-books from tiieir associated book displays. Preferably, tiie host 20 enforces a 

40 structure on tiie client site data base which is a queue of prices whose maximum display deptii is tiiat 
display deptii tiiat the host enforces for tiiat particular instiiament The IXM update message is a broadcast 
message which preferably contains a number of fields, such as the identifying information for tiie trading 
instrument tiiat is being effected by tfiis updated message, witti tiie information being tokenized in order to 
minimize the bandwidtfi used on tiie networi<. Thus, very short numbers are used to indicate tilings iike ttie 

45 fading instrument or the user or tfie subscriber tiiat the system is tying to affect. In this instance, the IXM 
update message instructs the client srte 26 to update tiie information being maintained in a particular 
tnstixjment and contains an IXM token. As shown and preferred in FIGS. 7 and 8. the IXM update message 
contains a number of fields for providing the requisite summary infonmation. such as tiie number of highs, 
lows, trades, etc.. which information is used to key into the rest of tiie message. Preferably IXM updates are 

50 cummulative and apply to tfie tiien cunrent state of tiie book maintained at the client site 26. Thus, the IXM 
update preferably contains new information about an IXM and the state in context of the insboiments book. 
The message is preferably of variable lengtfi and may or may not contain certain infonmation blocks. The 
IXM sequence number field preferably represents a number of updates to an IXM. The keystation 24 uses 
this value to preferably ensure tiiat it receives all updates to an IXM and that it does not apply an outdated 

55 update. The block list size preferably defines how many information blocks are required for tiie IXM. 
Preferably the size of tiie operations list may exceed the maximum size of tiie message. In such an 
instance, the DCM is segmented across multiple messages. The number of highs specifies tiiat a high quote 
is being sent, which typically would be only a one or zero. Similariy tiie number of lows specifics tiiat a low 
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quote is being sent, which would typically only be a one or a zero. The numter of trades preferably 
specifies the length of the trade list for the message which is used for the last trade statistic as well as for 
support of the ticker. Typically the IXM image would only have, at most, a single trade block to indicate the 
last trade if there was one. The number of operations preferably specifies the lengtfi of the operation list for 
5 the message. If tiie block list size does not equal the sum of the number of highs, number of lows, number 
of trades, and number of operations, the IXM has been segmented across multiple messages. At least one 
IXM segment message will tiien preferably follow. When the sum of all the number of highs, lows, trades 
and operations fields across the segmented messages equal the block list size, tiien preferably tiie IXM 
data set is complete. 

10 In order to get tiie book initially at ttie keystation, it is requested from the central system 20 during an 
initialization sequence. Thus, tiie first thing that a keystation 24 at a client site 26 does when it connects ttie 
network 22 and, ttiereby. tiirough to the central system 20, is to request a download of ail tfie cun'entiy 
active books. The host 20 tiien preferably sends a snapshot of each book and. from then on, tiie central 
system 20 will continue to send out updates on either a periodic basis or immediately after each change to 

75 indicate that the various items in the book have changed. 

It should be noted that, preferably, with a single parameter change at tfie host system 20. effectively tiie 
view which the entire "world" or system population obtains with respect to a particular instrument is 
effectively changed. In this regard, if the host system 20 sets the display depth equal to one then, 
preferably, that means that no one can look into the book and that the host will not send out updates off of 

20 the best price display. This display depth can, of course .be dynamically changed by the host on a daily 
basis or on any otiier periodic basis desired to provide centralized control over the distribution of the book. 
It should be noted that preferably all of the data in the system is logical data; tiiat is all of the fields have 
meaning to the system. 

In this regard, in order to understand the distributed book stnjcture of the present invention, it should be 

25 understood tiiat a book as used herein is tiie repository for bids/offer infonnaation on a particular trading 
instrument. Depending where tiiat book is maintained, the sort of Infonmation tiiat goes into it is going to be 
different so that tfie repository for bid/offer information on a given financial instrument, such as Japanese 
Yen. in tiie host 20 contains tilings like individual bids and offers, their identities, the clearing infonmation 
and all of tfiat maintained in strict price/time priority; whereas the book on Japanese Yen maintained at tiie 

30 client site 26 preferably contains some summary information about the total quantity bid and offered at a 
particular price, and does not contain all bids and offers, it only contains the ones that are appropriate. 

There arB actually two collections of information which are being maintained at tiie client site 26. One of 
these collections of infomnation is tiie book for each instrument which is maintained at the keystation 24 
sites which have been given reference numerals 110. 112. by way of example in FIG. 6. Anotiier book 

35 maintained at each site is tiie local entry data base or order book which has been given reference numerals 
114 and 116 in RG. 6. As previously mentioned, ttiere is also tiie host or system book database, given 
reference numeral 118 in FIG. 6. Each time a client site 26 starts up as a keystation 24, as was previously 
mentioned, tiie keystation 24 is preferably initially empty and requests ttie download of the currentiy active 
books from the central system 20. As was previously mentioned, separate books are maintained for each 

40 trading instrument, so tiiere would be a separate book for Japanese Yen, a separate book for Deutch Mark, 
a separate book for dollars, etc., assuming tiiat tiie system of tiie present invention was used for trading 
foreign exchange currencies. Each of tiiese books would be maintained at a given display deptii. In tiiis 
regard, It should be noted tiiat an IXM update broadcast message is only broadcast when ttie price 
information is Inside the assigned display deptii tiiat has been assigned by ttie host computer or central 

45 system 20. Witii respect to tiie local entry database or order books 114, 116, tiiese order books 114. 116 
are updated by directed messages from the central system 20 and/or record tiie orders of ttie particular 
keystation 24b or 24a which have been sent to ttie central system 20. In this regard, tiiese order books 114, 
116 are preferably kept current so that it is a listing only of orders which are still present in the central 
system 20 from ttie respective keystations 24b or 24a. This order database 114 and 116 gets modified. 

so such as tiirough ttie removal of data, due to various occurrences, such as when a complete match has 
occun-ed for a given order an entry remove message is provided, or if it is partial match you may get an 
entry message tfiat tells you ttiat only that a partial match has been done against that order. The match 
notification which was previously refen-ed to preferably refers to a particular order that is contained in the 
order database 114 or 116 and indicates what quantity or portion of tfie order has been matched. If all of 

55 tiie order has been matched, ttie entire order is ttien preferably deleted from ttie respective order database 
1 14 or 1 16. By way of example, if a bid were put in for ten million Yen at a price of 127 and the display was 
enabled, ttiat Is ttie display deptti was set to somettiing greater than or equal to one, ttien ttie central 
system 20 would preferably constmct a broadcast message, which Is the aforementioned IXM update 
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broadcast message, which would inform all client sites 26 that a new bid had been added to the Yen book, 
assuming that were the instrument being traded. The IXM update message would instruct an operation 
block which would say add to Index one the ten million at 127. As for the other parameters in the IXM 
update message, add index would equal one. type would equal bid, quote would equal 127 and quantity 

5 would equal ten million. In the above example, the transaction achieves two functions. The first function it 
achieves is that a bid is submitted and the host system 20 responds to the keystation 24a submitting the 
bid that the bid was accepted and that there was no ambiguity in that the bid is definitely in the system 20, 
the system 20 has it, and the local entry database 116 has it The other function indicates that the bid was 
of a certain characteristic that the rest of the "trading work!" in the system should know about and this is 

70 accomplished as a result of the IXM broadcast message which was generated to ail of the client sites 26 
which were then told about this in summary as opposed to being given all of the detailed information. It 
should be noted that, as previously mentioned, in terms of functional operation, the entry of a bid to the 
system is the same as entry of an offer. 

In the situation when a trade occurs, tills means that a matching offer is present in tiie system, the host 

75 system 20 has accepted that matching offer, and sends back the acknowledgment command, in effect 
retrieving the existing book on Yen, in the above example, finds out that there is ten million Yen at 127 in 
the book, adds to that the newly entered fifteen million and 127. and is aware that it has positioned fifteen 
million at 127. The host 20 then does the match up including that ten million and does the trade, taking out 
tiie existing bid. so it reduces that amount to zero million at 127 leaving over five million at 127 on the offer 

20 side. In this Instance, as will be explaned with reference to FIG. 6, at least two directed messages have 
been sent, actually four having been transmitted to the client sites 26 that are involved in the trade. The 
seller will get an indication that his Yen bid has traded by means of a match notification and he will, 
thereafter, be informed who the counterparty was after tiie match has been made. The clearing and 
settiement of the trade will then preferably be tiie responsibility of the subscribers. The counterparty who 

25 originally transmitted the offer and entry position message saying that ft had a Yen offer positioned greater 
tiian tfie bid will then get an entry positioned Yen offer at five million at 127 and will get a match notification 
saying that, witii respect to his offer, ten million of his original fifteen million has traded with the party who 
will tiien be identified Lastiy. the IXM update broadcast message will be constructed and broadcast to all 
client sites 26 to update tfie trading book. That update message will preferably, in tiie above example, 

30 contain two operation blocks, one which will remove the bid infomiation fi'om the client book and the second 
which will post the new five million offer which remains on tiie offer side and will show that a trade took 
place. In addition, as was previously mentioned, if desired, ticker information will also be provided in tiie 
IXM update message saying what traded, keeping track of the cummulative volume, the net change, ttie 
number of changes, ttie high limits, the low limits and so fortfi. It should be noted tinat preferably only ttie 

35 keystation 24 tfiat either executed the transaction or was involved somehow in tinat transaction will receive 
tiie directed message witii respect tiiereto and not other keystations 24 at the same client site 26, whereas 
with respect to broadcast messages all keystations 24 at all client sites 26 receive tiiese messages. If 
desired, with respect to credit, which does not fonnn part of the present invention herein, this can be 
controlled on a client site 26 by client site 26 basis as opposed to a keystation 24 basis. Thus, in tiie 

40 system of the present invention, the network 22 has two functions, one of which is directed message 
delivery and the otiier of which is broadcast message delivery. 

Referring now to RG. 6 in greater detail, the networit 22 which, as was previously mentioned, is 
transparent to transactional information has been omitted for purposes of explanation of the message flow in 
the system of the present invention, as has tiie risk control function using the transaction desks 70. to be 

45 described in greater detail witfi respect to RGS. 21-23. For purposes of tfie example of FIG. 6, keystation 
24a can represent any keystation which originates a transaction and keystation 24b can represent any 
keystations which are involved as counterparties in tiie transaction which, as was previously mentioned can 
be more than one keystation at more than one location. The keystations 24a and 24b are normally remotely 
located from each other such as. for example, keystation 24a tjeing in New Yori< and keystation 24b being 

so in London. In addition, tiie keystations 24a and 24 b are remotely located from tiie central system 20. In 
order to understand tfie message flow illustrated in FIG. 6, we will assume tiiat tiie originating keystation 
24a is receiving a display of tiie keystation book database located at keystation 24a. Assuming tiiat tiie 
operator at that keystation 24a tiien desires to enter a bid or an offer, either of which will be termed an 
order, tiiis information is input to tiie keystation 24a via conventional means, such as a keyboard or a 

55 mouse by way of example. The keystation 24a then preferably validates the onder and maintains its local 
order data base or local entry data base 116. The order, instead of being a bid or an offer, could be a hit or 
a take for a particular trading instrument as well since all of these various items would constitute an entry of 
an order. After tiie order has been entered, validated, and. the order data base 116 maintained, a 

10 



EP0 411 748 A2 



transaction message is built and sent as a directed message to the central system 20. This is represented 
by reference numeral 120 in FIG. 6. This transaction message 120 is received by the central system 20 and 
contains transaction information. At this point preferably the central system 20 sends back a directed 
message, termed a command acknowledgment message and given reference numeral 122, to inform 

5 keystation 24a that the transaction message 120 has been received. The transaction message 120 is time- 
stamped by the central system 20 at this point. Preferably the display of keystation 24a will indicate "please 
wart" until the transaction message 120 has been acknowledged. Preferably, such acknowledgment 
happens relatively quickly, such as in about two seconds, by way of example. The centra system 20 then 
preferably processes the transaction message 120 against the central system 20 stored copy of the system 

70 or host book which Is cont^ned In the host book data base 118 subject to gross counterparty credit limits. 
At this point, the central system 20 preferably either adds the entry of the transaction or the order from 
keystation 24a to the host book data base 118 or matches that entry against existing bids offers contained 
in the host tjook data base 118- Once that processing is completed, assuming the gross counterparty credit 
limit has not been exceeded, the central system 20 is ready to generate output messages not only to the 

75 originating keystation 24a, but possibly to other keystations 24 such as the counterparty keystations 
represented by 24b and, assuming the gross counterparty credit limit b>etween keystations 24a and 24b has 
not been exceeded and that an update message is required, to all keystations In the system. Thus, central 
system 20 generates directed messages back to each of the keystations 24 involved in the matching 
transaction, such as 24a as the originating keystation and, assuming that there is a match, 24b as the 

20 counterparty keystation, and generates the IXM update broadcast message to all keystations 24. It should 
be noted that, as previously mentioned, a single transaction message 120 from keystation 24a, whether it is 
a hit. or a take, or a bid. by way of example, could result in multiple matches. For example, if keystation 
24a wants to hit the bid for a quantity of 20, it is possible that to satisfy that order more than one match 
could be involved such, as for example, four or five different matches, particularly, since the keystation track 

25 at keystation 24a merely displays accumulated summaries of the bids or offers, such as represented by 
blocks 71. 80, 86 and 92 in FIG. 5. If multiple matches occur, then, thereafter, the identity of all of the 
counterparties involved in the multiple matches are displayed on the screen of the originating keystation 
24a for a settlement purposes. Thus, on any given transaction, there will always be directed messages 
involving the transaction originator and involving one or more counterparties or affected parties in that trade 

30 or transaction. If the market is an auction market then it preferably has a price depth of one so that this 
determines how many prices the central system 20 can maintain with only one price being maintained in an 
auction market When a new bid goes in which betters the existing bid in an auction market, the existing bid 
is actually removed and effectively cancelled in the book. By way of example, an auction market is 
represented by FIGS. 15 and 16. Preferably, after all of the directed messages are generated to the 

35 counterparties, and the associated directed message acknowledgments, such as represented by reference 
numerals 124, 126, 128 and 130 in FIG. 6, the IXM update broadcast message, represented by reference 
numeral 132 in FIG. 6. is sent to all keystations 24 in the system regardless of whether or not they were 
Involved in this particular matching transaction. It should be noted that preferably the first six steps 
illustrated in FIG. 6 with respect to the central system 20 are all essentially a-synchronous to any outside 

40 events. When the keystations 24a and 24b received the update broadcast message it will be processed 
against the local keystation book database 110, 112 and the local copy of the book will be maintained. As 
was previously mentioned, it should be noted that this local keystation book 110. 112 is not an exact cariDon 
copy of the central system book 118 but rather is only a selected subset of it which comprises an 
accumulated summary of bids and offers within the assigned display depth. Thus, preferably. FIG. 6 

45 illustrates a generic template for the processing of messages throughout the system of the present 
Invention in order to provide the distributed functionality of the system. 

It should be noted that the concept of originating keystation and counterparty keystation moves around 
with each transaction so that for each transaction the originator may be different and may for different 
transactions occurring at the same time bQ an originating keystation in one instance and a counterparty 

50 keystation in another instance. In addition, there are other instances in which the keystation may merely be 
a bystander and not involved in the particular transaction at all. Preferably the control of tiie overall 
distiibuted matching system is maintained by tiie central system 20 which operates in accordance with a 
set of rules, to be described in greater detail hereinafter, which govern how the transactions are processed. 
Preferably, the central system processes transactions against a particular trading instrument in time order of 

55 entry into the system. In this regard it should be noted that It Is not time entry of orders ^ se but time 
entry of orders related to a particular trading book or blading instrument Thus, there would be time order 
entry asagned to Yen. a different time order entry consideration assigned to Deutch Marks, and so forth if 
tiie trading instruments were foreign exchange currencies. 
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By way of example. RGS. 13. 14. 17 and 18 are further illustrations of the book market, with FIG. 13 
illustrating the book market entry position, at market, at the central data base; FIG. 14 illustrating the book 
market entry position for creation of a new sub-book; FIG. 17 illustrating a logical model of a book market 
after posting of a trade; and RG. 18 illustrating a logical model of the book market after the trade. 

5 Preferably each side of the book market Is made up of zero or more sub-books. In the example of FIG. 4, 
there are seven sub-books, four on the offer side and three on the bid side. Preferably there are two ways 
in which an entry can be positioned in a book market, both detemnined by the entry's value. If there exists a 
sub-book that has the same value as the new entry, the new entry is entered at the bottom of the sub-book, 
such as Illustrated in RG. 13. When the new entry equals the current best entry for the side of the market, 

10 the entry behaves in this fashion. If a sub-book with the same value as the new entry does not exist, then a 
new sub-book is created with the new entry placed at the top of the book, such as illustrated in RG. 14. 
This sub-book is preferably positioned between other sub-books so that the value ordering of the sub-books 
is preserved. Preferably by definition a best entry does not have a value equal to that of any existing sub- 
book for that side of the market A new sub-book is implicitly created when the new entry betters the 

75 current best price for that side of the market 

The behavior of an auction market, such as illustrated in FIGS. 15 and 16. is preferably dictated by the 
fact that there are at most one sub-book per side of a market When an entry is worse than the cun'ent best 
entry, it is preferably rejected from the market When an entry equals the current best enty, it is preferably 
accepted into the market and is positioned as the last entry in time order in the appropriate sub-book, such 

20 as shown in RG. 15 by way of example. When an entry betters the existing value for the side of a market, 
the current entries in that side of the book are preferably cancelled, such as shown in FIG. 16 by way of 
example. 

Referring once again to RG. 17 and 18. matching Is only attempted, preferably, when the posting 
function indicates that the best bid value is better than or equal to the best offer value. The matching 

25 function is preferably the same for both book martcets and auction markets. In a book market, it is possible 
for any order to cross the market; that is, for a new bid to be higher than the best offer or a new offer to be 
lower than the best bid. In this case, trades are preferably allowable at multiple quotes filling the order 
starting at the best quote and working down to the quote specified in the new order as necessary to trade 
as much quantity as possible. Since the quote depth for an auction market is only 1, just the bid side and 

30 the offer side of a market are submitted to matching. If one or more matches are found, the following 
information is preferably given for each matching pain namely, the buyer, the seller, the instilment the 
quantity fraded and the quote. As is shown by way of example in FIG. 17, tiiere is a bid which has been 
introduced at the value of 139.19, a value that betters the cunrent best bid. Since there exists no sub-book 
on this price on the bid side of the book, a new one is created. At this point, the best bid value is equal to 

35 the best offer value so the bid and offer sub-books with the value of 139.19 are submitted to the matching 
function. Assuming that the gross counterparty credit limit is not exceeded, then both of the offer enties are 
fully traded for a frade total quantity of nine. The bid is only partially traded and a quantity of one remains. 
It should be noted that with respect to FIG. 4, there are seven sub-books in the market, three on the bid 
side and four on the offer side with a value spread between the bid side and the offer side of the market 

40 currently existing so that no matching could take place at that time. FIG. 18 illustrates the logical model of 
the book market after the trade is over. In this Instance the offer sub-book with a value of 139.19 in the 
above example has no more entries in it so the sub-twok is removed. There is a bid remaining at that 
quantity so It remains in the sub-txxk. A new value spread now exists in the book. 

Thus, with the system of the present invention, the books may be disfributed among the keystations 

45 tiirough the use of summary books so that infomnation is distributed t>etween the central system 20 and the 
keystations 24 in such a way that all of the right information, and only the right infonmation. is made 
available at the geographically dispersed keystations. The keystations 24 need information to generate their 
displays which displays, in the system of the present invention, can be as up to date as possible so tiiat the 
fraders are provided with accurate information regarding tiie instruments available for trade while the 

50 keystations 24 are prevented from receiving disclosure information that they are not entitied to or that 
should be witiiheid from tiiem because it is an anonymous trading system. Thus, not only does the 
distributed risk control matching system of ttie present invention provide for efficient fransmission of 
information with a minimization of tosses due to broken trades, but it enables the host to controllably mask 
the ava table trading market 

55 Now refening to RGS. 19 and 20. tiie credit control function and the more quantity function of the 
system of the present invention shall now be described in greater detail. As was previously mentioned, 
there are two types of quantity in the system of the present invention; namely primary quantity and more 
quantity. Primary quantity is the amount which is disclosed in connection with the books distributed to the 
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keystations 24 from the host 20 whereas more quantity is kept anonymous by the system of the present 
Invention. Thus, the more quantity is not disclosed to the market at the time that the bid or offer is made 
but rather Is hidden. In addition, as previously mentioned, credit limits are also anonymous in the system of 
the present Invention. These trading party credit limits which are assigned by the individual keystations 24 

5 or client sites 26 to those other keystations 24 or client sites 26 in the system in which they wish to trade, 
or not trade as the case may be, are preferably held anonymously in the central system 20 which 
determines the gross counterparty credit limits. Thus, the only individuals who know what the trading credit 
limits are are the owners of those credit limits; that Is. the keystations 24 assigning the particular trading 
party credit limit. In this regard, If a trading party credit limit is set to zero then you will not trade with that 

10 party. Preferably, in determining the rules of matching to be applied by the system in the present invention, 
a bid can only match with an offer and an offer can only match with a bid. Thus, an order eligibility is 
preferably detenmined which says that eventually bids with offers, where there is a non-zero credit line 
between the counterparties for the same trading instrument, are eligible for a match where the buy price is 
greater than or equal to the sell price. Next, there should preferably be a quantity match, with the match 

75 quantity preferably being equal to the minimum of aedit, remaining quantity of the new order, or remaining 
of the standing order. Thus, the match quantity Is the minimum of these three things. In this regard, 
preferably the match may occur to the entirety of an order as opposed to distributing the order or match 
amongst several possible orders. In addition, preferably the priority of matching is based on time 
precedence; in other words, first in first out. Preferably the system of the present Invention tries to 

20 maximize the total trade size each time a match occurs. In determining standing order priority, preferably it 
is based first on price, second on quantity type, and tiiird on time stamp or time of entry into the system. 
Preferably in considering quantity type, the bid with more quantity is considered to be two bids, one of 
which is an offer of primary quantity at a certain price and tiien an offer for more quantity at a different 
price. Preferably the primary quantity has a higher priority than the more quantity type. By way of example 

25 in trying to understand the more quantity concept assume that there is a new order which is bid at a dollar 
for quantity of 30. The system will first detenmine that tiiis order should be matched against standing orders 
that are eligible. Assuming all tiie orders are eligible orders, then ttie system is going to say tiiat against 
each one it will trade up to its maximum and will keep trading until its ail done. In this regard, if in tiie 
course of matching you run up against a credit limit which causes the gross counterparty credit to be 

30 exceeded, tiien the matching trade occurs up to ttie gross counterparty limit so tiiat the match size is tiie 
minimum of the credit the standing order size or tfie primary size. As was previously mentioned, tiie 
system of tfie present invention basically operates witfi credit limits on tiie concept of gross counterparty 
limit In tiiis regard it is not enough for a keystation 24 to extend a trading party limit to a counterparty, it is 
also preferably necessary tiiat tiie counterparty extend a trading party credit limit to that keystation, in 

35 which Instance tiie minimum of the two trading party credit limits would represent the credit line or gross 
counterparty limit between the two keystations. By way of example, if ttie keystation 24a buys 10 million 
dollars worth of Deutch marks from anotiier keystation 24b and sells 10 million dollars wortii of Deutch 
marics to tiiat same keystation 24b. tiiat transaction would have consumed 20 million dollars of the gross 
counterparty credit limit between tiiese two keystations 24a. 26b. Of course, if desired according to the 

40 system of the present invention, any trading party credit limit can be changed or all credit limits may be 
reset. Preferably ttie minimum of the credit ttiat a keystation 24 has remaining with anotiier keystation 24 
and the credit tiiat tiiat keystation 24 has witfi tiie originating keystation 24 will determine tiie maximum 
possible match size. 

In addition to ttie above, tiiere is a credit alert tiireshold. Preferably tfie permission to modify credit 
45 limits in the system of ttie present invention is only given to somebody having tiiat special privilege. 
Preferably, if in ttie course of trading your credit remaining goes to a value less tfian 25% of tiie original 
value of ttie credit limit an alert is sent out to anybody witti permission to modify ttie limit Thus, tfie credit 
limit alert informs a particular keystation 24 that it is trading dangerously low to ttie assigned credit limits it 
has given and ttiat ttiose limits are going to start blocking or inhibiting trades if nothing is done about 
50 changing tiiem. As was previously mentioned, alttiough credit limits are assigned to individual keystations 
24 ttiey are held in tiie central system 20 so tfiat when a potential matching trade is to occur, it's not the 
keystation 24 function to detemiine the size of ttiat trade but rather it is ttie central system 20 function. 
Because of credit limits, it is possible tiiat a bid or offer could be put into the system which Is not capable 
of being matched witti any ottier bid or offer because all of the trading party credit limits assigned by the 
55 originating keystation 24 are zero or because no otiier keystation 24 in the system has extended a trading 
party credit limit to the new keystation 24 entering the system. 

Furthermore as previously mentioned, ttie matching algorittim employed In the central system 20 of the 
present invention preferably uses credit controls to determine the quantity of penmissable match to the 
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lowest common limit and the best bid/ask price for the largest available quantity to automaticaily complete a 
matching transaction or trade. Thus, a matching system is provided in which real time prices are the subject 
of real time credit. Moreover it should be noted that preferably prices of the best available bid are used to 
dynamically update prices. 

5 Summarizing the presently preferred matching rules for the system of the present invention, a new 
order is eligible to be matched with a standing order and a trade or matching transaction will result 
whenever one order is a buy order, the other is a sell onJer. the buy order and sell order originate from 
different entities, a non-zero and credit line exists between the two entities, the two orders are against the 
same instrument, and the price of the buy order is greater than that of the price of the sell order. Secondly, 

70 if an order match is possible according to the above criteria of order eligibility, then the trading transaction 
would take place at the price of the standing order preferably. Moreover if an order match is possible 
according to the criteria of order eligibility, then the trade will preferably take place for a quantity equal to 
the minimum of the available credit line, the remaining quantity of the new order, and the remaining quantity 
of the standing order. \A/hereas the order eligibility rule defines the criteria for matching, the quantity rule is 

15 used to define the size of an eligible trade. Preferably, if there are multiple standing order eligible for 
matching against a new order is then matches will be considered in priority sequence until one of the 
following conditions are obtained; namely the new order completely filled or all eligible standing orders have 
been considered. Thus, simply stated, each new order is traded to its maximum potential. Preferably the 
priority of the standing order relative to other standing orders for the same instalment is based on price. 

20 quantity type, and time stamp. With respect to price, for buy orders, preferably the higher price is the 
higher priority and for sell orders the lower price is the higher priority. With respect to quantity type, 
preferably a standing order for primary quantity has a higher priority than a standing order for more quantity 
if they are both at the same price. With respect to time stamp, preferably within the same price and same 
quantity type, older orders have a higher priority than more recent orders. Thus, the sort sequence for 

25 standing order priorities preferably by price, the quantity type, by time stamp. In this regard, however, if 
more quantity is at a better fill price, then it has a higher priority than primary quantity. 

Whenever a party initiates a credit change transaction which increases the credit extended to one or 
more counterparties the following sequence of events occurs: credit changes perfonmed; all the sut)scriber's 
bids and offers in crossed markets, which is a market in which to bid price is equal to or greater than the 

30 offer price, are evaluated for trade potential with standing orders on the opposite side of the book; if any 
single instrument contains multiple bids or offers from the entity who has performed the credit change, then 
these bids and offers are evaluated in time sequence; and if the party who has performed the credit change 
has bids and offers in multiple instruments with crossed markets, then the individual instruments are 
evaluated in an arijitrary sequence. 

35 Preferably, the system of the present invention supports four different order types which are used to 
buy or sell instruments in the matching system of the present invention. These order types are referred to 
as bid. offer, hit (also known as yours), and take (also known as mine). These orders are preferably 
differentiated from one another according to a set of time, price and size constraints which are either 
explicitly or implidty provided at the time of order entry. Preferably all system orders, regardless of type, 

40 are price limit orders. This means that the order, whether it be bid. offer, hit. or take, is preferably restricted 
to execute at the specified price or better. For a bid or take, the term "or better" preferably means at the 
specified price or lower, whereas for an offer or hit. this term preferably means at the specified price or 
higher. Furthermore, every system order must preferably cany one of two possible time constraints which 
are actually implied by the order type. Hit and take orders have the implied constraint fill-or-kil! (FOK). 

45 These orders must be fully or partially filled at the time they are presented and then they are removed from 
the system or killed. Bid and offer orders preferably have the applied constraint good 'till cancel (GTC). 
These orders preferably must remain in the system until explidty cancelled or until the end of the user's 
session. In addition to these order limitations, all orders must preferably specify primary quantity. In the 
case of bid and offer orders, more quantity may also be preferably Included with the order but only if a 

50 primary quantity is also included. FIG. 19 is aN illustration of ttie order types irhplemented in tiie system of 
the present invention witfi fill-or4cill represented by tiie expression FOK and good-till-cancei represented by 
the expression GTC. It should be noted that preferably hit or take specifies a price which crosses tiie 
mari<et tiiat is a hit with a price lower tiian the tkest bid, and is effectively a maricet order in the sense of the 
commodities markets and will execute at the best available price, and will go as far into the order book as 

55 needed until tiie order is filled or tiie limit price is reached. 

With respect to the credit control mechanism of tiie present invention, it comprises gross counterparty 
credit limit controls, as was previously mentioned. Thus each party is allowed to extend a credit limit or 
trading party credit limit to any other counterparty in tiie system, it is tiie act of extending a trading party 
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credit limit which allows trades to take place between two keystations 24. Assunning two keystations 24 
have each extended credit to one another, they will be allowed to trade until the remaining credit reaches 
zero. Every trade will draw down the available credit line for both sides of the trade and preferably, no trade 
may take place unless sufficient credit is available on both sides. 

5 Basically four credit control functions are implemented in the system in the present invention. TTiese 
functions are modified credit limits, reset credit limits, view credit limits, and credit limit alert. When the 
modified credit limits function is involved, the user is preferably presented with a list of all subscribers on 
the system. The user desirous of modifying credit limits may then assign a numerical credit limit to any 
subscriber in that list When complete, a new list of trading party credit limits is sent to the host or central 

70 system 20 thereby defining a new cunrent and future default credit limit for the originating subscriber. In 
addition, at any time, a user may invoke the reset credit limits function thereby resetting all counterparty 
credit limits to their original default values. This function would normally be performed prior to the start of 
trading each day. Credit limits are preferably reset for each counterparty to the last value specified in a 
modified credit limit function for that counterparty. In order for a trader to see how much of the original 

75 credit line remains to other subscribers, a view credit limits function may be selected. When this function is 
executed, the central system 20 preferably supplies a list of all counterparties to whom a credit line has 
been extended, together with the dollar amount of the original credit limit which remains. The information is 
preferably provided as a snapshot; namely, it will not dynamically update as trades take place. As was 
previously mentioned, the credit limit alert function identifies an impending total draw down of counterparty 

20 credit lines. Preferably, the credit limit alert is sent once for each trade performed after the 75% threshold is 
reached. The credit limit alert Is only preferably triggered when a trade occurs within the threshold region. If 
the credit becomes totally exhausted, then preferably no further trading will occur and no further alerts will 
be generated. Preferably, any user or keystation 24 may retrieve his and only his site's credit list for 
viewing only, with the information being presented, by way of example, in the form Illustrated in FIG. 20. In 

25 FIG. 20, the credit limit field is the maximum gross dollar amount of trading permitted between the 
requestor organization and the identified counterparty organization, and the credit remaining field is the 
original credit limit plus all trades executed since credit was reset with this counterparty. The display is 
preferably non-updating; that is the credit remaining column will not change once on display even if trades 
take place within the named organization. 

30 Thus, by using credit control in accordance with the present invention, subscribers may limit the 
amount of credit exposure they have with other subscribers in the system of the present invention, with 
credit control being managed as a gross counterparty limit extended on a subscriber-to-subscriber basis 
across ail trading instmrnents. In accordance with the system of the present invention, completion of 
potential matching transactions between transaction originating keystations and counterparty keystations are 

35 inhibited or blocked when the potential matching transaction has an associated value in excess of the gross 
counterparty credit limit. Thus, the credit control mechanism of the present invention controls who 
subscribers trade with in an anonymous trading system which Is important since the identities of the parties 
involved in a trade are not revealed until after the trade has taken place at a time which would be too late to 
unwind the trade. 

40 Refening now to the drawings in detail, and particularly to FIGS. 21-33. the presently pretended risk 
control aspects of the distributed risk control matching system of the present invention shall now be 
described in greater detail. Refen-ing initially to FIG. 21. I shall now explain how the system gets into a 
broken match situation where the various parties may not know precisely what has happened in the split 
seconds immediately before a failure. Once again, the networi< 22 has been omitted from FIG. 21 as have 

45 the various other portions of the system illustrated in FIG. 6 since they are necessary to understand the 
operation of the risk control aspect of the distributed risk control matching system of the present invention. 
Assuming for purposes of FIG. 21 . the host book data base 1 18 has an offer present from keystation 24a for 
10 million dollars of Yen at 1.7 and keystation 24b puts in a matching bid into the host database book 118, 
again, by way of example, putting in a matching bid for 10 million Yen at 1.7. As was previously discussed, 

50 the host 20 would respond with a match acknowledgment, perform the match and then send out a match 
notification in the form of a directed message to each of the two counterparties 24a and 24b with, in the 
above example, keystation 24a getting a match notification that it matched with keystation 24b at 10 million 
dollars of Yen at 1.7. and keystation 24b getting a match notification that it matched with keystation 24a, 
again for 10 million dollars of Yen at 1.7. In this manner, both parties to the transaction, keystations 24a and 

55 24b would know that they traded with other and the host 20 would record all this infonmation in a match log 
200. In reality, the preferred sequence of events, is that the match is processed by the host 20. is found to 
exist, the match is recorded in the match log 200, and thereafter, the counterparties to the match, 
keystations 24a and 24b are Infomned of the trade. Of course, in the above example, a broken match has 
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not occurred. However, there are several ways in which a broken match could occurr in the presence of a 
failure, such as. keystation 24 failure, a network 22 failure, or a host 20 failure. By way of example, I shall 
consider two such potential failures. 

Assume, for example, that keystation 24a who is the bidder in the above example, fails or is 

5 disconnected Immediately after submitting the bid for some reason or another and. thus, the network 
connection for keystation 24a fails. Thus, keystation 24a is then disconnected from the network 22. 
However, the host computer 20 is not yet aware of this and has presumably received the bid from 
keystation 24a and is now processing this bid to completion. As was previously discussed, once the host 20 
receives a message, it preferably does not stop for any reason in processing that message and processes it 

70 to completion regardless of what else has happened even though, in the above example, either the 
keystation 24a or the network 22 has failed. Thus, in the above example, a match would be generated and 
recorded in the match log 200 and. thereafter, as was previously explained, the host computer 20 would 
then send out match notifications to the counterparty keystations 24a and 24b. In this example, keystation 
24b. which is still connected to the network 22 and therefrom to the host computer 20, will still get its match 

75 notification; however, keystation 24a which has been disconnected from the network due to failure of the 
keystation 24a or the network 22 will not get its match notification. This will result in a broken trade where 
keystation 24b knows tiiat he has traded as a result of receiving the match notification but keystation 24a 
does not yet know that a trade has occurred. In an anonyomous matching system, once a trade has 
occurred due to a match, it is normally considered to have taken place even though one of the parties to 

20 the trade has not received a match notification. Thus, the risk control aspect of the present invention comes 
into play. Of course, if the host computer 20 falls before any match notification has been provided to any of 
the parties to the trade, then nothing has been written to the match log 20 and it is as If the trade has not 
taken place. Thus, in reality, tiiere are at (east three parties to every trade in tiie risk control distributed 
matching system of the present invention; namely, tiiere's a buyer, a seller, and the central system 20. 

25 Preferably, each live keystation 24 when it receives a match notification in the system of the present 
invention, it is preferably obliged to send back a positive match acknowledgment which indicates to tiie host 
computer 20 that this particular keystation 24a or 24b has received the matched notification and recorded it 
in its database 110 or 112. Thus, in this manner, tiie host computer 20 can readily determine whether any 
keystations 24a, 24b. by way of example, have failed and whetiier or not these keystations 24a, 24b have 

30 received their matched notifications from the host computer 20. Preferably, if a match acknowledgment 
signal is not returned from a keystation 24a or 24b witiiin a predetermined inten^al, tiien a broken trade alert 
occurrs and indicates to the host computer 20 that the particular keystation 24 has failed and should be 
otherwise notified of tiie cunrents of a match. In ttiis regard, in a foreign exchange currency trading mari<et, 
which is a dynamic market, time is of the essence and such notification should preferably be promptly 

35 provided. If, however, the host computer 20 fails, then a different type of situation must be set up in order to 
insure that any match which is recorded to the match log 200 is retrievable and can be used to notify the 
parties to that a trade has occurred. In order to do this, as shown and preferred in FIG. 21. the plurality of 
transaction dejecting computers or transaction desks, or T-desks. such as tiiree such computers 70a, 70b 
and 70c. are employed. As will be explained in greater detail hereinafter, these transaction computers 70a, 

40 70b and 70c preferably guarantee the recording of the details of each match before the match is written to 
the match log 200 so that even in the presence of a host computer 20 failure, the system will know >ft^at is 
potentially in the match log 200 and, tiierefbre. what is a broken match. 

Refer now to RQ. 22, the flow of messages and control between keystations 24a. 24b. host computer 
20, and the transaction computers 70a, 70b and 70c in order to implement the presently preferred risk 

45 control feature of the present invention is shown. Starting at the point in the match processing where the 
host computer 20 has already received a transaction from a keystation 24a and has concluded that it is 
about to process a match or produce a match, the host computer 20 determines all the details of a match 
but preferably does not yet write it to the match log 200. Instead, tiie host computer 20 first preferably 
broadcast all of these matched details to ail available transaction computers 70a. 70b and 70c in the above 

50 examples. At each of the transaction computers 70a. 7Gb and 70c, the match details are received and are 
recorded in the local database located at each of the transaction computers 70a, 70b and 70c. Preferably 
each transaction computer 70a, 70b, 70c keeps and identical local database of matched details that it has 
received from the host computer 20. At this point, each of the transaction computers a. 70b, 70c preferably 
starts a timer, such as preferably 15 to 20 ^conds, and the respective transaction computer 70a. 70b and 

55 70c send an acknowledgment or "vote" to the host computer 20, with each transaction computer 70a. 70b. 
70c preferably canning one acknowledgment or "vote" to send t>ack to the host computer 20. The host 
computer 20 preferably waits for all tiie transaction computers 70a, 70b and 70c to send an acknowledg- 
ment or "vote" back to the host computer 20, or tiie very least, preferably waits for a required minimum 
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number of acknowledgments or "votes" to come back from the transaction computer 70a. 70b and 70c. 
Typically, preferably the minimum number of "votes" required is something less than the maximum of 
available number of transaction computers 70a. 70b,.70c so that the potential for operating even in the 
presence of a given transaction 70a. 70b. 70c failure exists. In the above example of RG. 22 where three 

5 isolated computers 70a. 70b. 70c are shovm. a minimum number of two "votes" out of the three would 
preferably be satisfactory for a match to be completed. At this point, preferably no match notifications have 
yet gone out to the keystations -24. rather just the host computer 20 has notified the transaction computer 
70a, 70b, 70c that It has gotten match information and is almost ready to go. Thus, as long as the host 
computer 20 preferably receives a majority vote in the above example, the host computer 20 then 

10 concludes that it can committ to the match and pemnanently writes the match to its match log 200. After 
writing to the match log 200. the host computer 20 then notifies the aggressor and all the counterparties 24 
of this match by sending match notifications to these keystations 24a. 24b which, in turn, as was previously 
mentioned, send match acknowledgments, thereafter, back to the host computer 20. For each match 
acknowledgment received by the host computer 20, the host computer 20 forwards the acknowledgment 

75 onto the transaction computer 70a. 70b, 70c. When a transaction computer 70a. 70b, 70c receives a match 
acknowledgment for a particular match from the host computer 20, it preferably cancels the timer that it had 
started previously at the time it received the matched details initially from the host computer 20 and 
provided the "vote" or acknowledgment signal back to the host computer 20. In this regard, each 
transaction computer 70a, 70b, 70c is aware how many match acknowledgments are supposed to come 

20 back for each match with at least two such acknowledgments being required. If all of tiie required 
acknowledgments are not received by tine transaction computer 70a, 70b, 70c, and the timer expires, then 
the database is preferably checked to see which acknowledgments have been received and, thereafter the 
keystations which have not provided the required match acknowledgments are then preferably notified of 
tiie existence of the trade. If desired, depending on the trade rules set up in the system, if one of the 

25 parties does not receive a match notification because of a system failure, then tfiat party can be manually 
notified of tiie potential trade and given ttie option of eitiier completing the trade itself or, alternatively, the 
trade can be laid off on a bank of last resort, assuming tiiat the trading instruments are foreign exchange 
cunendes. Preferably, the multiple transaction computers 70a, 70b, 70c are located with at least one of 
tiiese computers 70c being remote from tiie otiier two 70a, and 70b. and witii two of these tiiree transaction 

30 computers preferably being co-located, 70a, 70b. In tills manner, preferably the two transaction computers 
70a and 70b which are co-located locally will "vote" very quickly and ttie system can then continue rapidly 
moving on so tiiat the trade rate does not have to be tiirottled back significantly in order to provide tiie 
desired risk cont'd. However, tiiis co-location would nomnally increase tiie risk tiiat both transaction 
computers 70a and 70b could be subject to a coordinated failure. Therefore, the third transaction computer 

35 70c is located remotely to minimize the risk tiiat all of tiie transaction computers 70a, 70b, 70c would be 
affected by common disaster. 

Anotiier potential risk control problem which the presently pretended system of the present invention 
seeks to avoid is that of a keystation 24 failure after a bid has been put into tiie system but before a match 
has occurred. If that bid is left in tfie system for any lengtfi of time after such failure, the probability tiiat 

40 some o will trade or match that bid is significantly increased. In order to minimize the risk of such broken 
fade, preferably, the window where ttie host computer 20 is unaware of a keystation failure must be 
preferably minimized. In tills regard, preferably as soon as ttie host computer 20 knows ttiat a keystation 24 
has failed or that conactavity with tfie other keystations in tiie system is lost, the host computer preferably 
cancels all bids and offers for that keystation 24 by removing them from the host database book 118. as 

45 long as no match has been completed. In onjer to accomplish this, as will be described in greater detail 
hereinafter, application based heartbeat signals are provided horn each of the keystations 24 to the host 
computer 20. An example of a network setup in order to monitor or re-route signals in connection with tiie 
presentiy preferred application based heartbeat signals is shown by way of example in FIG. 23. As will be 
described in greater detail hereinafter, the heartbeat signals and tiie transaction computer protocol 

50 described above, operate in conjunction to minimize risk. In tfiis regard, the previously mentioned 
fransaction computer 70a. 70b. 70c protocol and its associated "voting" protocol is the preferred manner in 
which broken fades are identified while the heartiDeat signals is tfie manner in which the incidents of such 
broken fades is, minimized. Of course, the aforementioned transaction computer 70a. 70b. 70c protocol 
would work even if heartbeat signals were not provided to minimize the inddents of broken fades, however, 

55 a much more effident and better risk confol system is provided if both of tfiese features are present By 
way of example, FIG. 23 shows the presence of five concenfator computers, such as the type of 
concentrators described in tiie previously mentioned patents of applicant's assignee relating to other foreign 
exchange dealing systems of said assignee. These conventional concenfator computers are labeled 202. 
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204. 206, 208, and 210 in FIG. 23 with the keystations 24a and 24b also being shown along with host 
computer 20. These concentrator computers 202, 204. 206, 208. and 210 preferably collect traffic from a 
number of different sources into a single "type" to the host computer 20 and operate such as switching 
nodes in the system of the present invention. In the example of FIG. 23, assume that a message path Is set 

5 up in keystation 24a. through concentrated 210, concentrated 208, concentrated 202, to the host computer 
20. The heartbeat protocol is essentially a periodic, irregular, periodic monitoring of the wellness of each 
link which is accomplished by sending a heartbeat message signal in both directions from the keystation 
24a up to the host computer 20 and from the host computer 20 back down to the keystation 24a. in the 
above example. In this regard, the keystation 24a sends a heartbeat message to concentrator 210 which in 

10 turn sends a heartt>eat message to concentrator 208 which in tum sends a heartbeat message to 
concentrator 202 which in tum sends a heartbeat message to host computer 20 and, thereafter, the reverse 
occurrs back down the link ultimately to the keystation 24a. Preferably, the heartbeat message is an 
application based on heartbeat message and maybe a regular data message or, altematively a non-data 
heartbeat message. Preferably, timers are employed to determine that the particular heartbeat message is 

75 received in a predetermined measurement interval, with the respective timers being preferably reset each 
time a heartiseat or regular message arrives at the designated point. If it is not received in a predetenmined 
time, then preferably, the link which fails to provide tiie heartbeat message is dissolved. Moreover, 
preferably if a link is dissolved in connection with the heartbeat protocol, ttien the entire root is dissolved. 
Preferably, the heartiaeat timer is set at a value that is high enough tiiat you can mask transients but still 

20 low enough to detenmine the period of time during which the system is vulnerable to broken t-ades. 
Preferably, this value is typically set at about an 8 second detection time. Thus, basically there are tiiree 
distinct risk control features going on in tiie presentiy prefen-ed system of tiie present invention: tfiere is tiie 
presence of positive match acknowledgments which are employed to determine consistency of tiie 
distributed network; the use of tiie isolated transaction computer 70a, 70b, 70c which "votes" to overcome 

25 failures of ttie central system or host computer 20; and tiie use of heartbeats to enable rapid detection and 
a loss of conactivity so tiiat entries from a failed keystation can rapidly be removed from tiie book 1 18. 

As also shown in and prefen^d in RG. 23. failures can be reconfigured around in the system of the 
present invention assuming that the failure is not due to the keystation 24a P£[ but rattier is due to one 
of tiie network links between the keystation 24a and tiie host computer 20. 

30 Referring now to Rgs. 24-33. trade arbiti-ation, which is tiie process by which a trading system decides 
whether to commit or abort a trade based on tiie cunrent system operating environment, shall be described 
in greater detail. Preferably, the system of tfie present invention supports two types of trade arbitration 
based upon the setting of a system-wide global parameter; one is termed host trade arbitration, which is a 
process which involves decision making in the host trading server 20 only; and tiie other is tenrted 

35 transaction desk or computer 70a. 70b. 70c arbitration with positive acknowledgement, which is the system 
described above with respect to Rgs, 21-23. 

In the process of host 20 trade arbiti*ators. the trading server 20 preferably commits or aborts the trade 
without regaro to external influences such as client-site 26. network 22, or transaction desk 70 failures. This 
process provides high transaction processing performance in conjunction with the ultimate detection of all 

40 broken trades. The maximum length of time that a broken trade can go undetected is limited to tiie 
maximum length of time it takes to recover tiie host system 20 in case of failure. By way of example, 
recovery could take approximately 180 seconds in the case of a single component failure. This estimate is 
obtained by adding a worst case cluster ti^nsition time of 75 seconds (HSC failure), a worst case database 
recovery time of 60 seconds, and an application startup and recovery time of approximately 45 seconds. 

45 Typical host recovery times for single component failures under such circumstances, are in the range of 3 
to 75 seconds. In tiie case of multiple component failures tiie recovery time could be much longer or 
recovery might not even be possible. If recovery is possible the recovery time would be given by tiie time it 
takes to repair enough of the components to arrive at a "workable" host 20 system. Simultaneous 
destruction of all database disks would effectively make recovery of tiie trade log and detection of broken 

50 trade impossible in tiie context of tiie host 20system. 

With respect to the aforementioned transaction desk or computer 70 ariDitiBtion with positive acknowl- 
edgement, as previously mentioned, this is a process which involves the host 20 and a set of transaction 
desks 70a. 70b, 70c in deciding tiie commit or abort status of each and every trade. In ttiis process the 
trading server 20, as was previously mentioned, commits or aborts the trade depending on the number of 

55 "votes" received from ttie active set of transaction desks 70a, 70b, 70c. The voting arrangement is typically 
adjusted so tiiat a minimum of one f ansaction desk 70 or two of three has recorded the possibility of the 
trade and has voted affimnatively to commit the trade before ttie frade is actually commited by the host 
computer 20. Client-site 26 or network 22 failures do not affect tiie commit or abort status of a trade once 
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the processing of the enclosing transaction has started. 

This process provides the same basic capabilities as the Host Trade Arbitration process in that all 
broken trades are detected, but with a smaller worstK^e detection time and better performance in the 
event of multiple failures. Preferably, in this process, the maximum length of time that a broken trade can 

5 go undetected is limited to the maximum of: the length of time it takes to recover the host 20 system in 
case of failure, and the length of time it takes a transaction desk 70 to detect a broken trade. As was 
previously mentioned, transaction desks 70 detect broken trades using their own internal timers. These 
timers can be set as low as desired. However, in order to avoid large numbers of false alarms, transaction 
desk 70 timers should preferably typically be set no lower than about 16 seconds. This value is obtained by 

70 the sum of the total network round trip delay [2 + 2 seconds], the worst-case network recovery time for 
recoveries which preserve the user session (8 seconds], and processing delays in keystation 24, host 20. 
and the transaction desk 70 processes [4 seconds total]. Single falures which take the host 20 out of 
service for longer than the transaction desk 70 timer, will preferably trigger broken trade alarms at all active 
transaction desks 70. Transaction desks 70 are preferably replicated so that single failures of transaction 

16 desks 70 will still allow triggering of broken trade alarms at all remaining transaction desks 70. Multiple 
failures consisting of a host 20 plus a transaction desk 70 will preferably trigger broken trade alarms at all 
remaining transaction desks 70. Simultaneous failure of all transaction desks 70 will preferably trigger a 
transaction desk 70 failure alanm at the host 20 force an abort and rollback of all cuaently in-progress 
trades before they become eligible to be broken, and force the host 20 into a non-trading mode. All 

20 outstanding matches cunrently involved In match acknowledgement would preferably continue to be 
monitored by the host 20. and match acknowledgement failures would result in broken trade alarms being 
presented to the operator console. Preferably, a simultaneous failure of the host 20 and all transaction 
desks 70 is considered a catastrophic failure and will not be recovered. The above T-desk arbitration 
process although being more beneficial, sacrifices some transaction processing performance in order to 

25 involve the independent transaction desk 70 entities in each and every trade. 

As was previously mentioned, Trade Arbitration exists in order to preferably place an upper limit on the 
length of time that a broken trade or match can go undetected. The fields contained in a typical match 
record, by way of example, are illustrated in FIG. 24. with the match records preferably being recorded in 
the match log 200. one record per match. The various portions of the match record shown in FIG. 24 are 

30 defined as follows. Buyer Notification Status and Seller Notification Status reflect the status of match 
notifications sent to the subscribers 24 and match notification acknowledgements received. Status reflects 
the overall status of the match and is calculated from the buyer and seller notification status fields by the 
match acknowledgement protocol which proves that it is always possible to determine if a match, and 
therefore a trade, is BROKEN or NON-BROKEN in finite time. A further refinement of this protocol shows 

35 that the BROKEN state can be further divided into SINGLY-BROKEN and DOUBLY-BROKEN sub-states. 
This refinement aids in the determination of appropriate recovery procedures. When a match is formed, 
both Buyer Notification Status and Seller Notification Status are set to UNKNOWN. This reflects the fact that 
no match notifications have yet been sent. Neither the buyer nor seller know they have been involved in tiie 
match. Notification has neither failed nor succeeded, therefore it is unknown. Match notifications are tiien 

40 sent to both buyer and seller, and timers are started to detect failure to respond. Each subscriber 24 
independentiy logs their match notification and acknowledges receipt by returning an acknowledgement 
message. If ttie buyer or seller acknowledgement returns, the appropriate field in tiie match record is 
updated to SUCCESS. If the buyer or seller acknowledgement timer has expired, tiie appropriate field in tiie 
match record is updated to FAILURE. Assume tiiat the host 20 has only two states: operation and failed. In 

45 the absence of host 20 failures, you are guaranteed that eittier tiie acknowledgement retums or tiie timer 
expires. Therefore, both buyer and seller notification status fields will fransition from ttie UNKNOWN state to 
eittier SUCCESS or FAILURE. In the presence of host 20 failures, (both/eitiier) buyer (and/or) seller 
notification status fields may be left in tiie UNKNOWN state. Therefore, on a host 20 failure and subsequent 
recovery, the system preferably scans all existing match records to find tiiose in which either the buyer or 

60 seller notification status' fields are UNKNOWN and sets tfiese to FAILURE. Now both buyer and seller 
notification status fields are in states SUCCESS or FAILURE. In any case (host 20 failure or not), when both 
buyer and seller notification status fields are in states SUCCESS or FAILURE tiiere is a clear indication of 
tfie combined SUCCESS or FAILURE of the match notification plus acknowledgement process itself. When 
botii buyer and seller notification stafais fields are in state SUCCESS tfiien the match is positively 

65 acimowiidgednSy'both parties . The match is then NON-BROKEN. Any otiier combination of states 
preferably yleldFa"BRbKEN"m^^~The BROKEN match state preferably consists of two sub-states: a 
one-way b^kirT state and alwo^ay broken state. These are called SINGLY-BROKEN and DOUBLY- 
BROKEN, respectively. The SINGLY-BROKEN state is obtained whenever one of ttie buyer or seller 
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notification status is SUCCESS. The DOUBLY-BROKEN state is obtained whenever neither buyer nor seller 
notification status is SUCCESS. Equivalently, one could transitively map the UNKNOWN state to the 
FAILURE state and arrive at identical conclusions. This allows treating broken trades differentty depending 
on host 20 failure-non-failure status since this information can be recovered by examining details of the 

5 match log 200. The above protocol preferably covers ail possible combinations of buyer and seller match 
acknowledgement states under all conditions of host 20 operation and failure, thus proving the con^ 
operation of the match acknowledgement protocol. 

Refening now to RG. 25. the field MATCH STATUS is a summary of the cun*ent settings of the BUYER 
and SELLER NOTIRCATION STATUS. MATCH STATUS is preferably computed according to the logic 

70 table shown by way of example, in Fig. 25. Since BUYER NOTIRCATION STATUS and SELLER 
NOTIRCATION STATUS each have three states, their combination preferably yields a total of nine 
composite states. Of these, only one state has both notification statuses set to SUCCESS; this is identified 
as the state MATCH STATUS = NON-BROKEN and shown as case 1 of Fig. 25. When a broken match is 
detected, an alarm is issued to an operator of the transaction desk 70. This person then preferably invokes 

75 manual recovery procedures to resolve any and all ambiguities about that match. This could involve one of 
several types of manual investigation and intervention depending on tiie type of match syndrome 
presented. In case of RG. 25, where tiie match is NON-BROKEN, it is not reported to the transaction desk 
70 as a tjroken trade. 

If the match is SINGLY-BROKEN witii explicit match notification FAILURE indications as in case 2 or 3 

20 of Rg. 25. by way of example, tiien preferably tiie subscriber 24 whose notification status was FAILURE is 
contacted by telephone or otiier means to detemnine the cause of the problem. If they received ttie match 
notification in question, then tiiey will say tiiey received it. and tiiey must accept the match as it stands. 
Thus, the match acknowledgement had been lost somewhere between the keystation 24 and the central 
system 20. If they did not receive tiie match notification in question, tiien they will say they did not receive 

25 it and they can accept the match as It stands or reject tiie match. Thus, tiie match notification was lost 
somewhere between the central system 20 and tiie keystation 24. If the subscriber 24 accepts the match, 
tiien tiie subscriber's notification status can be marked in some appropriate manner, such as 
"acknowledged via customer service intervention". If tiie subscriber 24 rejects tiie match, then tiie 
subscriber's match notification status can be appropriately mart<ed as "rejected via customer service 

30 intervention", and you must tiien go to tiie maxkoX to lay-off tiie broken fade, assuming that is one of the 
rules under which ttio system operates. If tiie match is SINGLY-BROKEN witii explicit match notification 
UNKNOWN indications as in case 4 or 5 of FIG. 25. then you preferably proceed as with case 2 or 3. 
recognizing that the broken trade was most likely caused by a host 20 failure. Since you do not know 
exactiy tfie time of host 20 failure, it is not possible to know tiie true state of the subscriber 24 match 

35 notification. It is possible tiie match notification was never sent to tiie subscriber 24. or tfie match 
acknowledgement was never received by tiie host 20. or tiie host 20 feuled before logging ttie match 
notification to the database 118. Combined failures are also possible. For example, the host 20 could send 
tiie match notification, tiien fail; yet tiie match notification could fail to anive at tfie subscriber site 24 due to 
a network 22 failure. This much, at least is known: one subscriber 24 received a match notification and ttie 

40 database 118 recorded ttie match acknowledgement while tiie other subscriber 24 may not have received 
anything. Recovery operations can proceed as witii case 2 or 3 above. If the match is DOUBLY-BROKEN, 
witii explicit match notification FAILURE indications as in case 6 of FIG. 25. then a network 22 failure is tiie 
most likely cause since a host 20 failure is ruled out The investigation should proceed to determine if one 
or botti subscribers 24 received match notifications. If one subscriber 24 received a match notification and 

45 tiie otiier did not tiien you should preferably proceed as with case 2 or 3. If neitiier subscriber 24 received a 
match notification, then tiie transaction desk 70 can ask them whether or not ttiey wish to consummate the 
match. If both subscrit)er5 24 accept the match, tfien each subscriber's notification status can be 
appropriately marked as "acknowledged via customer service intervention". If both subscribers 24 reject the 
match, tfien each subscriber's match notification status can be appropriately mariced as "rejected via 

50 customer service intervention". If tiie match is DOUBLY-BROKEN, witii a mixture of match notification 
UNKNOWN and FAILURE indications as in case 7. 8 or 9 of FIG. 25, tfien a host 20 failure is the most 
likely cause. The investigation can tiien preferably proceed as witii case 6 above. 

Refemng now to RGS. 26-33. ttie processing of trades using the transaction desks 70 shall be 
described. FIG. 26 preferably shows ttie major steps in the processing of various trade and nontrade-types 

$5 of transactions using the transaction desk 70. FIG. 26 will be used to discuss the details of control and data 
flow for a set of transactions in twth normal and failure modes of the system of the present invention. FIG. 
26 descnljes ttie various steps in trading with T-desk type ariDitration, witfi Step 0 describing tfie non-trade 
bid/offer transaction. Step 1 describing tiie single-ti^e bid/offer transaction. Step 2 describing ttie match 
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notification acknowledgement transaction, and Step 3 describing the host match notification time-expiration 
transaction. For this discussion. I shall assume there are three keystations 24 connected to the system 
labeled KSa, KSb. KSc and representing the traders of three different subscribers A. B, C. I also assume that 
there are three transaction desks 70 labeled Tdeski, Tdeska, Tdeska. I further assume that one instrument 

5 (ixM) is available for trading among all three subscribers 24 and that all subscribers 24 have credit with 
each other. Trading starts with an empty book. The subscribers 24 submit a total of four transactions Xtem = 
Xi , X2. Xa, Xi at the same quote (price) in the order shown, by way of example, in FIG. 27. If we look at the 
sequence of transactions in the order given in the example of FIG. 27 and follow their progress through the 
system from the point of origin to the final effect this would give a view of the data flow. 

10 If, however, we change our viewpoint and discuss the processing of the same set of transactions as 
seen by each sut)system, we would present pseudo-code and more detail on the flow of control. Now, by 
way of example. I shall proceed by examining the details of transaction processing for the four transactions 
Xt, X2. X3. X4. In transaction 1 of FIG. 27, subscriber A submits a bod for Quantity = 15 with an All-Or- 
None restriction. Message processing is shown in "Step 0" of FIG. 26. The message processing is as 

T5 follows: 

Keystation KSa generates a bid message which is sent to the I/O server of the host 20; the I/O Server 
validates and logs the trigger and sends a trigger acknowledgement to the keystation 24; the I/O Server 
transports the bid to the Trading Server; the Trading Server positions the bid in the book 118 for that IxM 
and generates two messages: a directed message to KSi indicating successful positioning; and a broadcast 

20 message to all keystations 24 indicating the new status of the IxM. The I/O Server transports the Bid 
Positioned message to KSa- Keystation KSa receives the Bid Positioned message and updates its local 
copy of subscriber A's "Open Positions". The I/O Server ttien broadcasts the IxM Update message to all 
keystations 24. All keystations 24 receive the IxM update message and update their local copies 110, 112 of 
the IxM summary data. The state of the book 118 after completion of Xi is as illustrated in FIG. 28 in which 

25 the book 1 18 has no latent trade. Thus ends tiie processing of the transaction 1 . 

Transactions 2 and 3 of FIG. 27 preferably proceed in the same way as transaction 1 , except for tiie 
differences in subscriber ids (B and C), types of entry, quantities, and attributes. After transaction X2, we 
preferably have a book 118 witti one bid and one offer as shown in FIG. 29. This book 118 cannot trade 
because botii entries have all-or-none quantity restrictions and different quantities. The state of the book 

30 118 just after transaction X3 is as shown in RG. 30. Again tills book 118 contains no latent trades t)ecause 
entries (1) and (2) cannot trade because tiiey have all-or-none quantity restrictions and different quantities 
and entry (3) preferably cannot trade witii entry (2) because tiiey belong to the same subscriber. Of course, 
if desired, such trading can be pennnitted. Thus, transactions 1, 2 and 3 are all trading-type transactions 
which do not result in a trade because of a blocking condition. "Step 0" of FIG. 26 preferably serves as tfie 

35 model for message processing for these types of transactions. 

In transaction 4 of FIG. 27. subscriber C, submits a bid for Q = 15, unrestricted as to quantity. 
Message processing is preferably shown in "Step 1 " of FIG. 26. If you look at the state of ttie book 1 18 just 
before the matching analysis step of Xi. you would see a book 118 witii two bids and two offers such as 
shown in FIG. 31. This book 118 has a latent trade consisting of X^(J^{M (A.{ B, 10), M( A,2 C. 5). M^ (B. C. 

40 10))). Thus this is the first transaction of the four being described which is sent to the I/O server of tiie host 
20. The I/O Server then validates and logs the trigger and sends a trigger acknowledgement to ttie 
keystation 24. The I/O Server also transports tfie bid to ttie Trading Server; tiie Trading Server positions tfie 
bid in the book 118 for that IxM and discovers tiiat a ti^e is possible. The Trading Server 20 tiien 
constructs the Match Set for the trade and sends tfie set to tiie Trade Arbiter. The Trade Arbiter receives 

45 tiie Match Set from Trading Server 20 and starts a "Match Set Voting" timer which is preferably used to 
time-out unresponsive transaction desk 70 processes. The transaction desk 70 processes register tiie match 
set In their local databases and start a "Match Set Acknowledgement timer which is preferably used to 
time-out ttie match set if all subscriber-site 24 acknowledgements are not received in a fixed amount of 
time; each transaction desk 70 supplies a "Vote 1" back to the trade arbiter to positively acknowledge tiie 

50 registration of ttie match set; as was previously mentioned, ttie Trade /Arbiter waits until a sufficient number 
of votes have been collected or tfie match set acknowledgement timer times out Assuming that sufficient 
votes are received to indicate commit, then the Trade Arbiter cancels the match set acknowledgement timer 
and sends a status message to tiie Trading Server indicating that a commit of the trade is allowable. The 
Trading Server receives ttie commit indication from ttie trade arbiter and generates several messages such 

55 as a directed message to KSc indicating successful positioning of ttie bid. directed messages to all 
subscribers or keystations 24 in ttie match set notifying ttiem ttiat ttieir entries have been involved in a 
trade, witti a total of 6 such match notifications being generated in tiie example of RG. 32. and a broadcast 
message to all keystations 24 indicating ttie new status of ttie IxM (empty). 
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The I/O Server transports the Bid Positioned message to KSc. 

Keystation KSc receives the Bid Positioned message and updates its local copy of subscriber C*s 
"Open Positions". The I/O Server preferably starts a "Match Acknowledgement" timer for each match 
notification shown in RG. 32. This timer wili preferably be used to time-out the individual subscriber-site 

5 match acknowledgements if they are not received in a fixed amount of time. The I/O Server preferably 
transports the Match Notifications to all keystations 24 in the match set Each keystations 24 preferably 
receives its sutjset of Match Notifications and updates its local database 110. 112, 114. 116 to reflect the 
change to tfieir open orders, and indicates in its log that a match has occun-ed. This is similar to the 
registration step performed by the transaction desk 70 as previously described. 

10 Each keystation 24 must preferably subsequently send a match acknowledgement to the host 20 to 
positively acknowledge receipt of the match notification. The I/O Server preferably tiien broadcasts the IxM 
Update message to all keystations 24, which 110. 112 receive the IxM update message and update their 
local copies of the IxM summary data. This ends processing of Transaction 4. 

Transaction 4 as shown in FIG. 32, preferably initiates tfie production of six more host 20 transactions 

75 X5,...Xio since each match notification must preferably be acknowledged witii a distinct message back to 
the host 20. Assuming that tiie acknowledgements come back in tiie same order as the original 
notifications, tiie resulting match acknowledgements are shown in FIG. 33. 

In HG. 33. From: KS and Qualifications are used to associate the match acknowledgement with the 
original match notification. Of course, any identification scheme which accomplishes the association of 

20 match acknowledgement with the original notification could be used, such as original TSN. Trade Sequence 
Numbers, or From: Subscriber and Match Sequence Numbers shown in FIG. 33. Transactions 5-10 shown 
in FIG. 33 are called "match-acknowledgement transactions" and, preferably, all follow the general outline 
shown in "Step 3" of FIG. 26. Thus. Keystations KSx generates a match acknowledgement message which 
is sent to tiie I/O server of the host 20; tiie I/O Server validates the match acknowledgement message, 

25 converts it to an internal trigger (no acknowledgement back to the keystation 24 is required), and logs the 
trigger; the I/O Server cancels tiie match acknowledgement timer for tiie associated match notification; the 
I/O Sender transports the match acknowledgement timer for the associated match notification; the I/O Server 
transports the match acknowledgement of tfie Trading Sen/er; ttie Trading Server starts a transaction, 
updates tiie Match Log to Indicated that the given match Mj* (x.y) has been acknowledged and commits tiie 

30 transaction; the Trading Server fonwards the match acknowledgement to tiie trade arbiter; the Trade Arbiter 
broadcasts the match acknowledgement to all active transaction desks 70; and the transaction desks 70 
receive tiie client-site match acknowledgement and update ttieir copy of tiie match set to register the 
acknowledgement If all matches in the match set have been mart<ed as acknowledged, then the "Match Set 
Acknowledgement" timer Is preferably cancelled and tiie match set is de-registered. In tiiis example. Xs, 

35 Xe, X7, Xs. and Xs, will find that some elements of the match set have not been acknowledged, so tiie timer 
will be in effect. X10 will find tfiat all acknowledgements have anived, tiie timer will be cancelled and the 
match set will be de-registered. This ends the processing of Transactions 5-10. 

The ti^saction processing load presented by transactions 5-10 is non-neglible since each one involves 
a per-match transaction against tiie recoverable database and each transaction performs relatively littie 

40 woric. If desired, tiie impact of these transactions may be reduced in tiie following manner. In general, a 
transaction which resulted in m matches would result in 2m match notification messages, 2m match 
acknowledgement messages, and 2m match acknowledgement transactions. If the host 20 were processing 
an average of X trading transactions per second and p of these resulted in trades then the number of match 
acknowledgement transactions would be 2pXm [sec~^]. In normal operation, all 2m match acknowledge- 

45 ment messages would arrive back at the host 20 at about ttie same time, approximately one network 22 
round-trip time ( Tround-tnp) after tiiey were sent. One could tiierefore simply buffer all match acknowledge- 
ment messages from a given transaction for some fixed length of time, say 2 ^round-trip or 3 ^round-trip, 
and then update all match log 200 entries for Uiese match acknowledgements in a single transaction against 
the database. Here, the reduction in transaction processing cost would be proportional to 2m, since roughly 

50 2m MATCH-ACK updates would be committed per transaction and the rate of MATCH-ACK transactions 
would be reduced to pX [sec"M- If desired, one could buffer all match acknowledgement messages for all 
transactions for some fixed length of time, or until some pre-designated maximum number of match 
acknowledgements had arrived, and tiien update the database. This procedure would give even more 
reduction In transaction processing cost as compared to a per transaction MATCH-ACK updating procedure 

55 since tfie rate of MATCH-ACK transactions is essentially constant. The system would actually gain in 
efficiency as tfie toad increased, since as more matches were committed per unit time, more MATCH-ACK 
transactions would be collapsed into a single transaction with essentially constant cost 

The above example may also be described by descrit>ing the process of transactions from tfie 
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perspective of the individual subsystems involved. This perspective would more clearly show the functions 
performed by the different subsystems and show how the combined effect of all subsystems implements 
the required level of fault tolerance and reliability in the system of the present invention. In the foltowing 
description, a combination of pseudo-code and a narrative description will be used. The pseudo-code is an 
informal programming language and is not intended to be compilable. The pseudo-code is annotated with 
comments beginning with a double dash (-): these comments provide additional explanation or cross 
references to the step numbers of RG. 26, starting with a description of keystation 24 processing which 
treats only production of triggers and receipt of messages from the network 22. The appropriate pseudo- 
code is as follows: 

~ [Stop xl Transactionos Trigger Production, Message 
^ *^ * processing 
Entity : Keystation 

loop 

Wait for user Input or Message from Network 

''''^^o"?riSri Siwer Message - BID/OPFER/HIT/TAKE etc- 
Send Trigger (via Hetwork) to Host 

when Message from Network -> 
Process Message 
Log Message 

if Message requires ACK then 

Sf nd Ack (via Network) to Host 
end tt 

end loop 



Next referring to the host 20 components namely, the Trading Server. Trade Arbiter, and I/O Server, 
the component pseudo-code is as follows starting with the I/O Server first and describing the processing 
perfonned for all inputs, outputs and timers, with this model being a good overview of the processing for all 
transactions: 
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— [Step X] Transact ions s Trigger Inputs 

^- : Directed Message Output, 

: Broadcast Message Output 

g ~ Entity « I/O Server 

loop 

Wait for aaseage from NetworK 

or message from Trading Server 
^0 Timer Expiration 

when Message from Network •> 
Assign Transaction Kunber 
Log the Trigger 
75 if Message requires ACK then 

Validate Trigger 

if Valid Trigger then 

Send Command Ack (via Network) to Keystation 
20 Route Trigger to Trading Server 

end it 

when Message from Trading Server •> 
if Directed Message then 
Write Directed Log 
if Message Reguires ACK then 

Start Timer 
end if 

Send Message to Keystation 

. end i£r 

30 

if Broadcast Message then 
Write Broadcaet Log 
Send Message to all Keystations 

end i:^ 

35 



when Timer Explrations> 

Determine Reason for Expiration 
Generate Appropriate Internal Trigger 
Assign Traneaotion Number 
Log the Trigger 

Route Trigger to M>propriate Server 
end loop 



In the cases of Match Notification Acknowledgement and Match Notification Timer expiration, we can be 
more specific, if a match notification is received at the I/O Server before expiration of tlie timer, then the 
timer is cancelled, an internal trigger is generated Indicating Match Notification Success, and this trigger is 
forwarded to the Trading Server, such as illustrated below: 
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[Step 2] Tranaaction: Match Notification Acknovladgaxaant 
Entity t I/O Sarv^r 

Recelva Client (Match Kotificatlon AcXnovledgenent} 
5 Cancal Cliant Match Acknovledgement Timar 
Generate Internal Trigger 
Assign Transaction Kunbar 
Log the Trigger 

Send Trading Server (Hatch Acknovledgeinent Trigger) 



If however, a match notification is not received at the I/O Server before expiration of the timer, then a 
match notification failure trigger is generated as shown below: 



~ [Step 3] Transaction: Match Notification Timer Expiration 
Entity : 1/0 Server 

A Client has not ACKed a message that required an ACK. 
~ Either the client (ailed, or a network link failed. 
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Match Notification Timer Expires 
Generate Internal Trigger 
Assign Transaction Number 
Log the Trigger 

Send Trading Server (Match Acknowledgement Failure) 

The next host 20 component is the Trading Server, with the below example being slanted toward 
processing of transaction 4, and transactions 1-3. following a model which is simply a subset of the 
processing for transaction 4 and. thus, is not being repeated here in the below example: 
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~ [Step 11 Tranflactioni Trade origination 
Entities : Trading Server 

Receive Client (Trigger) — bid or OFFER 
Begin Transaction 



[Step 1.1] 

Begin Trade 

Construct Match Set 

Send Trade lurbiter (Natch Set) 

Receive Trade Arbiter (Status) 

if status Success then 

loop over all Matches in Match Set 
Mark Both client AcXs as Unknown 

end loop 

safe Store Match Set 
Commit Trade 

else 

Rollback Trade 
end it 
End Trade 

[Step 1.2] 

if Status s Success then 

loop over all Matches in Match Set 

Start Client Match Kotifieation Timer 
Send client Match Notification 

end loop 

else 

do nothing 
end it 



End Transaction 



With respect to the general flow of transactions 5-10 in the Trading Server, these transactions involve 
the processing of match notification acknowledgements for client sites 26 which conBsponds to "Step 2" of 
RG. 26 as shown below: 

- [Step 21 Transaction: Match Xcknowledgaoent succja. 
^ *^ variablea : Client C, Tranaactlon X, Trada T, 

Hatch K 
Entitlaa ; Trading Server 

Receive Client (Match XcKnowledgeoent Succeaa) 
Baglh Transaction « i.^v 

^ Locate Match X (T(M)) within .-xed 

Hark Client c Ack of Hatch Set M as cllent-ACKad 

Cosmit Transaction . ^ . . 

sand Trade Arbiter (Match AcKnowledgenant) 

End Transaction 

If a match notification is not received at the I/O Server before expiration of the timer, then a match 
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notificalion failure trigger is generated and anrives at Trading Server and is processed as follows: 

— [Step 3] Traneaction: Natch Acknowledgement JailufJ 

— variables : client C, Transaction X, Trade T, 

Match N 
Entitle* t Trading Server 

Receive client (Match AcHnowledgeaent Failure) 

Hotel Failure le indicated by timer expiration 

— or network notification of lose of connection. 
Beoin Transaction 

Locate Match X(T(M)) within Match Log 



Mark Client C Ack of Match Set M ae Client-HACKed 

Commit Tranaactlon , 

Send Trade Arbiter (Match Acknowledgement) 

End Transaction 

With respect to the Trade Arbiter, it is preferably only involved in transactions which result in a trade or 
process a match acknowledgement success/failure trigger. In general, the Trade Arbiter acts as an "I/O 
Server" for transaction desk 70 processes. In a trade transaction, the Trade Arbiter broadcasts match sets 
to all available transaction desk 70 processes and waits for the votes to come in as follows: 

— [Step 1] Transaction: Broadcast Match Set. to Trade Judges 
__ ^ ^ ^ Entity X Trade Arbiter 

Receive Trading Server (Match Set) 
Start judgment Timer 

MlSl5\m Votes » weighting (Current Judges) 

— Broadcast the Match Set to all Judges 
for I in Current Judges 

loop Current Judges ^ w » 

Send Trade Judge (I) (Match Set) 
end loop 

— wait for results to arrive 
while Judgment Timer not Expired 

and Votes Minimum vote* 

^°**^Receive Trade Judge (Vote) 

Votes • votes + Vote 
end loop 

— Decide if results Indicate success/Abort 
if Votes >= Minimum Votes then 

Send Trading Server (Success) 

Send Trading Server (Abort) 
end it 

When match acknowledgements come back, the Trade Arbiter preferably broadcasts the acknowledge- 
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ments to all transaction desk 70 processes so that they can mark ACKs or NACKs on their local copies of 
the match set as shown below: 

[Step 2] Transaction: Broadcaat Match Acknowladgement Status 
i^tlty : Trado Arbiter 

Receiving Trading Server (Hatch Acknowledgement (Status) ) 
for I in current Judgee 
loop Current Judges 

Send Trade Judge (Match Acknovledgement (Statue) } 
end loop 



As was previously mentioned, transaction desks or computers 70, casting votes which ultimately decide 
whether a trade commits or aborts. During the trade origination part, the transaction desk 70 simply records 
the data being "judged" nd cast their vote. They each start a timer which determines the maximum length 
of time to wart for Match Acknowledgement Status to come back from the host 20 such as shown below: 

~ [Step 11 Transaction: Register a Match Set for Tracking 
Entity : Transaction Desk (or Trade Judge) 



Receive Trade Arbiter (Hatch Set) 
Safe Store Match Set 
Send Trade Arbiter (Vote l» 1} 
Start Match Acknowledgeiaent Timer 



During steps 2 and 3 each transaction desk 70 preferably collects match Acknowledgement Status 
messages from the host 20 and marks the matches appropriately. If all matches become marked, then we 
can have an early determination of Match Set success or failure, can cancel the timer, and can inform the 
trade desk 70 person of broken trades, if any such as shown below: 



[Step a, 3] Transaction: Match Acknowledgement 

SuccesB/Failure 
Entity I Transaction Deek (or Trade Judge) 

Receive Trade Arbiter (Hatch Acknowledgement) 
Locate Match K within Match Set 
Mark Client C of Match M ee Client-ACKed or NAKed 
if all Cliente of Hatch Set have been marked then 

Cancel Match Acknowledgement Timer 

— Look for Broken Trades 

scan Match Set for miseing ACKe or explicit NAXs 
if Broken Trade then ^ ^ ^ 

Notify (with Alarm) T-Deek Personnel of Broken Trade 
Identify Clients with missing ACKs or explicit naks 
end if 



end if 



Thus, by utilizing the risk control distributed anonymous matching system of the present invention, risks 
are minimized as to losses due to broken trades by utilizing a plurality of isolated computers to monitor 
eadi trade and vote on its completion, by monitoring heartbeat messages to minimize the incidence of 
broken trades, and by pt^tive match acknowledgements, with broken trade alerts being provided where 
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appropriate so that all parties can be made aware of a broken trade and correct the situation. 



Claims 

5 

1. A risk control matching system for trading instruments in which bids are automatically matched against 
offers for given trading instruments for automatically providing matching transactions in order to complete 
trades for said given trading instruments, said system comprising a host book database comprising all of 
the active bids and offers in the system by trading instrument; a transaction originating keystation means for 

10 providing a bid on a given trading instrumerrt to said system for providing a potential matching transaction, 
a counterparty keystation means for providing an offer on said given trading instrument Involved in said 
potential matching transaction; networtc means for interconnecting said host computer means, said transac- 
tion originating keystation means and said counterparty keystation means in said system for enabling data 
communications therebetween; and a plurality of matching transaction by said host computer means for 

15 detecting the occurrence of said potential matching transaction by said host computer means, each of said 
transaction detection means having an associated datatjase for storing data with respect to said potential 
matching transaction, said host computer means further comprising means for processing said potential 
matching transactions for a given trading Instrument for providing a match indication signal to said plurality 
of transaction detecting means, said transaction detecting means comprising means responsive to said 

20 match indication signal for detecting the occurrence of said potential matching transaction at said host 
computer means, said transaction detecting means further comprising means for providing an acknowledge- 
ment signal to said host computer means in response to receipt of said match indication signal and for 
recording said potential matching transaction in said transaction detecting means associated data base, said 
host computer means further comprising means responsive to receipt of a predetenmlned plurality of said 

25 acknowledgement signals from said transaction detecting means for updating said host book data t>ase 
based on said matching transaction and for providing a directed message to said transaction originating 
keystation means and said counterparty keystation means acknowledging the occun'ence of said matching 
transaction; whereby broken trades may be readily identified with a minimization of risk to the parties to 
said potential matching transaction. 

30 2. A risk control matching system in accordance with Claim 1 wherein said transaction originating keystation 
means and said counterparty keystation means comprise means for providing directed messages to said 
host computer means, corresponding to said bid and said offer, respectively, said directed messages 
updating said host book, said transaction originating keystation means and said counterparty keystation 
means comprising means for providing a positive match acknowledgement signal to said host computer 

35 means in response to receipt of a match notification signal from said host computer means, lack of said 
receipt of said match acknowledgement signal from either of said keystation means causing said host 
computer means to detect a broken trade. 

3. A risk control matching system in accordance witi) Claim 1 or Claim 2 wherein each of said keystation 
means comprises means for providing an application based heartbeat signal to said host computer means 

40 for enabling rapid detection of keystation failure, said host computer means further comprising means for 
cancelling all bids and offers associated witii any keystation means from which said heartbeat signal is not 
detected in a predetermined detection inten^al. 

4. A risk control matching system in accordance witii Claim 3 wherein said application based heartbeat 
signal comprises a data message or a no data heartbeat message provided in a predetemnined heartbeat 

45 interval less than said detection interval. 

5. A risk control matching system as claimed in any one of Claims 1 to 4 wherein said predetermined 
detection interval is at value high enough to make transients but still low enough to minimize system 
vulnerability to broken trades. 

6. A risk control matching system- as claimed in any one of Claims 1 to 5 wherein said predetermined 
50 detection Interval comprises about an 8 second detection time. 

7. A risk control matching system as claimed in any one of Claims 1 to 6 wherein at least two of said 
plurality of matching transaction detection means are substantially collocated and at least one other of said 
plurality is remotely located from said other two. 

8. A risk control matching system as claimed in any one of Claims 1 to 7 wherein said fransaction 
55 originating keystation means and saud counterparty keystation means comprise means for providing 

directed messages to said host computer means, comesponding to said bid and said offer, respectively, 
said directed messages updating said host book, said transaction originating keystation means and said 
counterparty keystation means comprising means for providing a positive match acknowledgment signal to 
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said host computer means in response to receipt of a match notification signal from said host computer 
means, lack of said receipt of said match acknowledgment signal from either of said keystations means 
causing said host computer means to detect a broken trade. 

9. A risk control matching system as claimed in any one of Claims 1 to 8 wherein each of said associated 
keystations means further comprises an order book, said order book comprising the orders being 
maintained by said associated keystation means in said system, said order books being updatable in 
response to directed messages from said host computer means. 

10. A risk control matching system as claimed in any one of Claims 1 to 9 wherein said given trading 
instruments comprise foreign exchange currencies. 
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